breakpoint commands no more working due to MI front-end

Mirror of the gdb mailing list
 help / color / mirror / Atom feed

* breakpoint commands no more working due to MI front-end
@ 2006-01-23 11:32 David Lamy-Charrier
  2006-01-23 13:51 ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: David Lamy-Charrier @ 2006-01-23 11:32 UTC (permalink / raw)
  To: GDB List

Hello,

I am using minGW GDB 6.3.1 on a windows XP Pro PC, and I am using
breakpoint commends to do some tasks each time a breakpoint is reached
and then continue execution.
Everything is working really fine with GDB only and with Insight.
(this is definitely a powerfull feature, I can also use hook-stop to
do the same ).

But when I try it with Eclipse front-end connected to gdb through MI
commands, it stops working:
GDB stops on my breakpoint but it does not execute the commends
associated to the breakpoint and it does not continue execution.

I turned on MI logs to see what happens and it appears that GDB sends
a "*stopped\n" message to Eclipse, Eclipse sends commands to get infos
on threads, stack frame... and GDB never executes my commands and
never continue execution.

Has anybody already encountered this problem ?
Do you think it will be easy for me to modify GDB to workaround this
problem? any hints on the files I should looked at ?

Thanks in advance,
David

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 11:32 breakpoint commands no more working due to MI front-end David Lamy-Charrier
@ 2006-01-23 13:51 ` Daniel Jacobowitz
  2006-01-23 15:52   ` David Lamy-Charrier
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2006-01-23 13:51 UTC (permalink / raw)
  To: David Lamy-Charrier; +Cc: GDB List

On Mon, Jan 23, 2006 at 11:41:32AM +0100, David Lamy-Charrier wrote:
> Hello,
> 
> I am using minGW GDB 6.3.1 on a windows XP Pro PC, and I am using
> breakpoint commends to do some tasks each time a breakpoint is reached
> and then continue execution.
> Everything is working really fine with GDB only and with Insight.
> (this is definitely a powerfull feature, I can also use hook-stop to
> do the same ).
> 
> But when I try it with Eclipse front-end connected to gdb through MI
> commands, it stops working:
> GDB stops on my breakpoint but it does not execute the commends
> associated to the breakpoint and it does not continue execution.
> 
> I turned on MI logs to see what happens and it appears that GDB sends
> a "*stopped\n" message to Eclipse, Eclipse sends commands to get infos
> on threads, stack frame... and GDB never executes my commands and
> never continue execution.
> 
> Has anybody already encountered this problem ?
> Do you think it will be easy for me to modify GDB to workaround this
> problem? any hints on the files I should looked at ?

There is not enough information here to understand your problem.
Can you send a full log of the communication between GDB and Eclipse
that shows what's going wrong?

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 13:51 ` Daniel Jacobowitz
@ 2006-01-23 15:52   ` David Lamy-Charrier
  2006-01-23 17:05     ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: David Lamy-Charrier @ 2006-01-23 15:52 UTC (permalink / raw)
  To: GDB List

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

Daniel,

Thanks for your help.
Here attached is a log between Eclipse and GDB.
GDB stops on a breakpoint where it is supposed to display a value and
then continue.
Unfortunately, it seems that it first informs Eclipse that it stops
and Eclipse query infos about threads, stack-frame... and the commands
attached to the breakpoint are never executed.

When GDB stops on a breakpoint with commands associated, does it
inform the front-end with MI commands ? if yes, is it after executing
the commands or before ?

Thanks,
David


On 1/23/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Jan 23, 2006 at 11:41:32AM +0100, David Lamy-Charrier wrote:
> > Hello,
> >
> > I am using minGW GDB 6.3.1 on a windows XP Pro PC, and I am using
> > breakpoint commends to do some tasks each time a breakpoint is reached
> > and then continue execution.
> > Everything is working really fine with GDB only and with Insight.
> > (this is definitely a powerfull feature, I can also use hook-stop to
> > do the same ).
> >
> > But when I try it with Eclipse front-end connected to gdb through MI
> > commands, it stops working:
> > GDB stops on my breakpoint but it does not execute the commends
> > associated to the breakpoint and it does not continue execution.
> >
> > I turned on MI logs to see what happens and it appears that GDB sends
> > a "*stopped\n" message to Eclipse, Eclipse sends commands to get infos
> > on threads, stack frame... and GDB never executes my commands and
> > never continue execution.
> >
> > Has anybody already encountered this problem ?
> > Do you think it will be easy for me to modify GDB to workaround this
> > problem? any hints on the files I should looked at ?
>
> There is not enough information here to understand your problem.
> Can you send a full log of the communication between GDB and Eclipse
> that shows what's going wrong?
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

[-- Attachment #2: eclipse_gdb_log.txt --]
[-- Type: text/plain, Size: 19454 bytes --]

[1,138,028,135,264] 95^done
[1,138,028,135,275] (gdb)
[1,138,028,265,662] 96-exec-continue
[1,138,028,265,682] 96^running
[1,138,028,266,073] (gdb)
[1,138,028,266,083] 96*stopped
[1,138,028,266,083] 97 info threads
[1,138,028,266,083] (gdb)
[1,138,028,266,083] &"info threads\n"
[1,138,028,266,163] ~"  40 thread 2272.0xf78  "
[1,138,028,266,163] ~"  39 thread 2272.0xb48  "
[1,138,028,266,163] ~"  38 thread 2272.0xb30  "
[1,138,028,266,173] ~"  37 thread 2272.0x794  "
[1,138,028,266,173] ~"  36 thread 2272.0x990  "
[1,138,028,266,173] ~"  35 thread 2272.0x5c0  "
[1,138,028,266,373] ~"  34 thread 2272.0xf00  "
[1,138,028,266,373] ~"  33 thread 2272.0x330  "
[1,138,028,266,373] ~"  32 thread 2272.0xdd0  "
[1,138,028,266,373] ~"  31 thread 2272.0xbb4  "
[1,138,028,266,373] ~"  30 thread 2272.0x388  "
[1,138,028,266,373] ~"  29 thread 2272.0x468  "
[1,138,028,266,373] ~"  28 thread 2272.0xc6c  "
[1,138,028,266,373] ~"  27 thread 2272.0xc14  "
[1,138,028,266,373] ~"  26 thread 2272.0xc9c  "
[1,138,028,266,373] ~"  25 thread 2272.0x358  "
[1,138,028,266,373] ~"  24 thread 2272.0x56c  "
[1,138,028,266,373] ~"  23 thread 2272.0xe18  "
[1,138,028,266,373] ~"  22 thread 2272.0xa14  "
[1,138,028,266,373] ~"  21 thread 2272.0xef0  "
[1,138,028,266,373] ~"  20 thread 2272.0x370  "
[1,138,028,266,373] ~"  19 thread 2272.0x914  "
[1,138,028,266,373] ~"  18 thread 2272.0xc40  "
[1,138,028,266,373] ~"  17 thread 2272.0xfa0  "
[1,138,028,266,383] ~"  16 thread 2272.0x530  "
[1,138,028,266,383] ~"  15 thread 2272.0x968  "
[1,138,028,266,383] ~"  14 thread 2272.0x894  "
[1,138,028,266,383] ~"  13 thread 2272.0xb14  "
[1,138,028,266,383] ~"  12 thread 2272.0x3c4  "
[1,138,028,266,383] ~"  11 thread 2272.0xc5c  "
[1,138,028,266,383] ~"  10 thread 2272.0xeec  "
[1,138,028,266,383] ~"  9 thread 2272.0x694  "
[1,138,028,266,383] ~"  8 thread 2272.0x130  "
[1,138,028,266,383] ~"  7 thread 2272.0x714  "
[1,138,028,266,383] ~"  6 thread 2272.0x9a8  "
[1,138,028,266,383] ~"  5 thread 2272.0x6c  "
[1,138,028,266,383] ~"  4 thread 2272.0x870  "
[1,138,028,266,383] ~"  3 thread 2272.0xfbc  "
[1,138,028,266,383] ~"  2 thread 2272.0xfe0  "
[1,138,028,266,383] ~"* 1 thread 2272.0xaac  "
[1,138,028,266,383] 97^done,frame={addr="0x7c90eb94",func="ntdll!LdrAccessResour
ce",args=[],from="nt\
dll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="
ntdll.dll"},frame={a\
ddr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame=
{addr="0x7c90eb94",f\
unc="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94"
,func="ntdll!LdrAcce\
ssResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAc
cessResource",args=[\
],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args
=[],from="ntdll.dll"\
},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dl
l"},frame={addr="0x7\
c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0
x7c90eb94",func="ntd\
ll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="n
tdll!LdrAccessResour\
ce",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessReso
urce",args=[],from="\
ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from
="ntdll.dll"},frame=\
{addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},fram
e={addr="0x7c90eb94"\
,func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb9
4",func="ntdll!LdrAc\
cessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!Ldr
AccessResource",args\
=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",ar
gs=[],from="ntdll.dl\
l"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.
dll"},frame={addr="0\
x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr=
"0x7c90eb94",func="n\
tdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func=
"ntdll!LdrAccessReso\
urce",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessRe
source",args=[],from\
="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],fr
om="ntdll.dll"},fram\
e={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},fr
ame={addr="0x7c90eb9\
4",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90e
b94",func="ntdll!Ldr\
AccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!L
drAccessResource",ar\
gs=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",
args=[],from="ntdll.\
dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdl
l.dll"},frame={addr=\
"0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={add
r="0x7c90eb94",func=\
"ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",fun
c="ntdll!LdrAccessRe\
source",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccess
Resource",args=[],fr\
om="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],
from="ntdll.dll"},fr\
ame={addr="0x7c90eb94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},
frame={addr="0x7c90e\
b94",func="ntdll!LdrAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c9
0eb94",func="ntdll!L\
drAccessResource",args=[],from="ntdll.dll"},frame={addr="0x7c90eb94",func="ntdll
!LdrAccessResource",\
args=[],from="ntdll.dll"},frame={func="dbg_module_break2",args=[],file="../dbg_d
ll.c",line="65"}
[1,138,028,266,393] 98-stack-info-depth
[1,138,028,266,393] (gdb)
[1,138,028,266,393] 98^done,depth="52"
[1,138,028,266,393] 99-stack-list-frames 0 52
[1,138,028,266,403] (gdb)
[1,138,028,266,403] 99^done,stack=[frame={level="0",addr="0x0448137b",func="dbg_
module_break2",file=\
"../dbg_dll.c",line="65"},frame={level="1",addr="0x044813e1",func="dbg_module_br
eak",file="../dbg_dl\
l.c",line="89"},frame={level="2",addr="0x037513aa",func="ope_set_module_function
",from="C:\\Document\
s and Settings\\dlamy\\My Documents\\Open-Plug\\My Environments\\FWK_ADVANCED_ec
lipse_1_5_1_35\\Bin\\
\X86_Components\\op_engine_lib.dll"},frame={level="3",addr="0x03b9f014",func="??
"},frame={level="4",\
addr="0x03b9f1f0",func="??"},frame={level="5",addr="0x00000000",func="??",from="
"},frame={level="6",\
addr="0x03b6c08c",func="??"},frame={level="7",addr="0x0012f944",func="??"},frame
={level="8",addr="0x\
03751356",func="ope_set_module_function",from="C:\\Documents and Settings\\dlamy
\\My Documents\\Open\
-Plug\\My Environments\\FWK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\op_e
ngine_lib.dll"},fram\
e={level="9",addr="0x03b9f014",func="??"},frame={level="10",addr="0x03b9f1f0",fu
nc="??"},frame={leve\
l="11",addr="0x00000000",func="??",from=""},frame={level="12",addr="0x03b6c08c",
func="??"},frame={le\
vel="13",addr="0x0012f944",func="??"},frame={level="14",addr="0x00000003",func="
??"},frame={level="1\
5",addr="0x0012fb48",func="??"},frame={level="16",addr="0x00000000",func="??",fr
om=""},frame={level=\
"17",addr="0x00000000",func="??",from=""},frame={level="18",addr="0x00000003",fu
nc="??"},frame={leve\
l="19",addr="0x03b9f1f0",func="??"},frame={level="20",addr="0x03b6c08c",func="??
"},frame={level="21"\
,addr="0x00000000",func="??",from=""},frame={level="22",addr="0x00000000",func="
??",from=""},frame={\
level="23",addr="0x000ffffc",func="??"},frame={level="24",addr="0x61e847d5",func
="??"},frame={level=\
"25",addr="0x00007143",func="??"},frame={level="26",addr="0x00000000",func="??",
from=""},frame={leve\
l="27",addr="0x61e847d5",func="??"},frame={level="28",addr="0x00007143",func="??
"},frame={level="29"\
,addr="0x00000000",func="??",from=""},frame={level="30",addr="0x61e847d5",func="
??"},frame={level="3\
1",addr="0x00007143",func="??"},frame={level="32",addr="0x00000000",func="??",fr
om=""},frame={level=\
"33",addr="0x37343544",func="??"},frame={level="34",addr="0x31363845",func="??"}
,frame={level="35",a\
ddr="0x31373334",func="??"},frame={level="36",addr="0x0012fb00",func="??"},frame
={level="37",addr="0\
x037343cd",func="op_engine_lib!acq_set_get_file_policy",from="C:\\Documents and
Settings\\dlamy\\My \
Documents\\Open-Plug\\My Environments\\FWK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_C
omponents\\op_engine\
_lib.dll"},frame={level="38",addr="0x00000000",func="??",from=""},frame={level="
39",addr="0x00000003\
",func="??"},frame={level="40",addr="0x0012fb48",func="??"},frame={level="41",ad
dr="0x00000000",func\
="??",from=""},frame={level="42",addr="0x00000000",func="??",from=""},frame={lev
el="43",addr="0x0000\
0006",func="??"},frame={level="44",addr="0x00000004",func="??"},frame={level="45
",addr="0x00000001",\
func="??"},frame={level="46",addr="0x0379e07c",func="??"},frame={level="47",addr
="0x00010003",func="\
??"},frame={level="48",addr="0x00000000",func="??",from=""},frame={level="49",ad
dr="0x0173a593",func\
="??"},frame={level="50",addr="0x00000045",func="??"},frame={level="51",addr="0x
000ffffc",func="??"}\
]
[1,138,028,266,413] 100-data-list-changed-registers
[1,138,028,266,413] (gdb)
[1,138,028,266,413] 100^done,changed-registers=["3","4","5"]
[1,138,028,266,413] 101 info sharedlibrary
[1,138,028,266,413] (gdb)
[1,138,028,266,413] &"info sharedlibrary\n"
[1,138,028,266,413] ~"DLL Name
                    \
                                                                      Load Addre
ss\n"
[1,138,028,266,413] ~"ntdll.dll
                    \
                                                                      7c901000\n
"
[1,138,028,266,413] ~"C:\\WINDOWS\\system32\\kernel32.dll
                    \
                                                                         7c80100
0\n"
[1,138,028,266,423] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\OP_Util.dll                 1
0001000\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\xerces-c_2_5_0.dll
                    \
                                                                         1200100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\advapi32.dll
                    \
                                                                         77dd100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\rpcrt4.dll
                    \
                                                                         77e7100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\msvcrt.dll
                    \
                                                                         77c1100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\user32.dll
                    \
                                                                         77d4100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\gdi32.dll
                    \
                                                                         77f1100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\shell32.dll
                    \
                                                                         7c9c100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\shlwapi.dll
                    \
                                                                         77f6100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\ole32.dll
                    \
                                                                         774e100
0\n"
[1,138,028,266,423] ~"C:\\WINDOWS\\system32\\oleaut32.dll
                    \
                                                                         7712100
0\n"
[1,138,028,266,443] ~"C:\\WINDOWS\\system32\\qt-mt323.dll
                    \
                                                                         39d0100
0\n"
[1,138,028,266,443] ~"C:\\WINDOWS\\system32\\imm32.dll
                    \
                                                                         7639100
0\n"
[1,138,028,266,443] ~"C:\\WINDOWS\\system32\\winspool.drv
                    \
                                                                         7300100
0\n"
[1,138,028,266,443] ~"C:\\WINDOWS\\system32\\msvcp60.dll
                    \
                                                                         7608100
0\n"
[1,138,028,266,443] ~"C:\\WINDOWS\\system32\\rasapi32.dll
                    \
                                                                         76ee100
0\n"
[1,138,028,266,453] ~"C:\\WINDOWS\\system32\\rasman.dll
                    \
                                                                         76e9100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\ws2_32.dll
                    \
                                                                         71ab100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\ws2help.dll
                    \
                                                                         71aa100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\netapi32.dll
                    \
                                                                         5b86100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\tapi32.dll
                    \
                                                                         76eb100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\rtutils.dll
                    \
                                                                         76e8100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\winmm.dll
                    \
                                                                         76b4100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\version.dll
                    \
                                                                         77c0100
0\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\msvcirt.dll
                    \
                                                                         0032100
0\n"
[1,138,028,266,463] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\MemoryDriver.dll            0
0341000\n"
[1,138,028,266,463] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\CommonDriver.dll            0
0361000\n"
[1,138,028,266,463] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\OP_Audio_Driver.dll         0
0371000\n"
[1,138,028,266,463] ~"C:\\WINDOWS\\system32\\dsound.dll
                    \
                                                                         73f1100
0\n"
[1,138,028,266,463] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\OP_Input_Driver.dll         0
03a1000\n"
[1,138,028,266,463] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\OP_Trace_Driver.dll         0
03c1000\n"
[1,138,028,266,463] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\OP_Screen_Driver.dll        0
0431000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\TelDriver.dll               0
0451000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\PluginDriver.dll            0
0471000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\SystemDriver.dll            0
0491000\n"
[1,138,028,266,473] ~"C:\\WINDOWS\\WinSxS\\x86_Microsoft.Windows.Common-Controls
_6595b64144ccf1df_6.\
0.2600.2180_x-ww_a84f1ff9\\comctl32.dll                                   773d10
00\n"
[1,138,028,266,473] ~"C:\\WINDOWS\\system32\\comctl32.dll
                    \
                                                                         5d09100
0\n"
[1,138,028,266,473] ~"C:\\WINDOWS\\system32\\uxtheme.dll
                    \
                                                                         5ad7100
0\n"
[1,138,028,266,473] ~"C:\\WINDOWS\\system32\\SynTPFcs.dll
                    \
                                                                         6300100
0\n"
[1,138,028,266,473] ~"C:\\WINDOWS\\system32\\msctf.dll
                    \
                                                                         7472100
0\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\TelSimDriver.dll            0
35e1000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Systems\\dbg_w4\
c\\Bin\\X86_Components\\elips_boot_component.dll                               0
3711000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\op_engine_lib.dll           0
3731000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\elips_bs.dll                0
3771000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\elips_midi_file_player.dll  0
3db1000\n"
[1,138,028,266,473] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\elips_fw.dll                0
3dd1000\n"
[1,138,028,266,483] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\op_device.dll               0
3e01000\n"
[1,138,028,266,483] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\elips_telephony.dll         0
3e71000\n"
[1,138,028,266,483] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\op_gtk.dll                  0
3e91000\n"
[1,138,028,266,483] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\sms_sar.dll                 0
11c1000\n"
[1,138,028,266,483] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\elips_audio.dll             0
3ec1000\n"
[1,138,028,266,483] ~"C:\\Documents and Settings\\dlamy\\My Documents\\Open-Plug
\\My Environments\\F\
WK_ADVANCED_eclipse_1_5_1_35\\Bin\\X86_Components\\dbg_dll.dll                 0
4481000\n"
[1,138,028,266,483] 101^done

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 15:52   ` David Lamy-Charrier
@ 2006-01-23 17:05     ` Daniel Jacobowitz
  2006-01-23 17:37       ` David Lamy-Charrier
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2006-01-23 17:05 UTC (permalink / raw)
  To: David Lamy-Charrier; +Cc: GDB List

On Mon, Jan 23, 2006 at 04:45:51PM +0100, David Lamy-Charrier wrote:
> Daniel,
> 
> Thanks for your help.
> Here attached is a log between Eclipse and GDB.
> GDB stops on a breakpoint where it is supposed to display a value and
> then continue.
> Unfortunately, it seems that it first informs Eclipse that it stops
> and Eclipse query infos about threads, stack-frame... and the commands
> attached to the breakpoint are never executed.
> 
> When GDB stops on a breakpoint with commands associated, does it
> inform the front-end with MI commands ? if yes, is it after executing
> the commands or before ?

Looks like breakpoint commands are just broken with MI.  I think it has
something to do with the event loop; GDB has too many different ones
still lying around for me to be sure what's going on.  But I think a
call to bpstat_do_actions in mi_execute_command or
mi_execute_command_wrapper might do it.

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 17:05     ` Daniel Jacobowitz
@ 2006-01-23 17:37       ` David Lamy-Charrier
  2006-01-23 17:47         ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: David Lamy-Charrier @ 2006-01-23 17:37 UTC (permalink / raw)
  To: GDB List

Thanks Daniel for the idea, I am going to try it.

But if I am right, mi_execute_command is called to handle MI commands
from the front-end, so it is already too late to execute the commands
associated with the breakpoint.
The commands should have been executed before and the front-end should
even not be notified that GDB stopped and continued, no?

Thanks,
David

On 1/23/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Jan 23, 2006 at 04:45:51PM +0100, David Lamy-Charrier wrote:
> > Daniel,
> >
> > Thanks for your help.
> > Here attached is a log between Eclipse and GDB.
> > GDB stops on a breakpoint where it is supposed to display a value and
> > then continue.
> > Unfortunately, it seems that it first informs Eclipse that it stops
> > and Eclipse query infos about threads, stack-frame... and the commands
> > attached to the breakpoint are never executed.
> >
> > When GDB stops on a breakpoint with commands associated, does it
> > inform the front-end with MI commands ? if yes, is it after executing
> > the commands or before ?
>
> Looks like breakpoint commands are just broken with MI.  I think it has
> something to do with the event loop; GDB has too many different ones
> still lying around for me to be sure what's going on.  But I think a
> call to bpstat_do_actions in mi_execute_command or
> mi_execute_command_wrapper might do it.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 17:37       ` David Lamy-Charrier
@ 2006-01-23 17:47         ` Daniel Jacobowitz
  2006-01-23 17:53           ` David Lamy-Charrier
  2006-01-23 17:58           ` Bob Rossi
  0 siblings, 2 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2006-01-23 17:47 UTC (permalink / raw)
  To: David Lamy-Charrier; +Cc: GDB List

On Mon, Jan 23, 2006 at 06:05:45PM +0100, David Lamy-Charrier wrote:
> Thanks Daniel for the idea, I am going to try it.
> 
> But if I am right, mi_execute_command is called to handle MI commands
> from the front-end, so it is already too late to execute the commands
> associated with the breakpoint.
> The commands should have been executed before and the front-end should
> even not be notified that GDB stopped and continued, no?

That would require a much bigger change to the way GDB works.  We've
been talking about some related changes; the general question is
whether the MI front end should know that something other than itself
has caused the inferior to change state.  This is vital to have
multiple interpreters active at the same time.

Given how MI works and is defined today, I don't think breakpoint
commands make a whole lot of sense: your front end should supply the
commands when it sees the breakpoint.  Is there a reason you can't make
CDT do that?

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 17:47         ` Daniel Jacobowitz
@ 2006-01-23 17:53           ` David Lamy-Charrier
  2006-01-23 17:58           ` Bob Rossi
  1 sibling, 0 replies; 10+ messages in thread
From: David Lamy-Charrier @ 2006-01-23 17:53 UTC (permalink / raw)
  To: GDB List

Thanks Daniel,

I have a setup with a gdbscript that uses breakpoint commands which is
working fine with GDB and Insight, keeping exactly the same script for
Eclipse and letting the user choose its prefered debugguer front-end
would have been nice...

I will try your idea with bpstat_do_actions in mi_execute_command.

Many thanks again,
David

On 1/23/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Jan 23, 2006 at 06:05:45PM +0100, David Lamy-Charrier wrote:
> > Thanks Daniel for the idea, I am going to try it.
> >
> > But if I am right, mi_execute_command is called to handle MI commands
> > from the front-end, so it is already too late to execute the commands
> > associated with the breakpoint.
> > The commands should have been executed before and the front-end should
> > even not be notified that GDB stopped and continued, no?
>
> That would require a much bigger change to the way GDB works.  We've
> been talking about some related changes; the general question is
> whether the MI front end should know that something other than itself
> has caused the inferior to change state.  This is vital to have
> multiple interpreters active at the same time.
>
> Given how MI works and is defined today, I don't think breakpoint
> commands make a whole lot of sense: your front end should supply the
> commands when it sees the breakpoint.  Is there a reason you can't make
> CDT do that?
>
> --
> Daniel Jacobowitz
> CodeSourcery
>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 17:47         ` Daniel Jacobowitz
  2006-01-23 17:53           ` David Lamy-Charrier
@ 2006-01-23 17:58           ` Bob Rossi
  2006-01-23 19:34             ` Daniel Jacobowitz
  1 sibling, 1 reply; 10+ messages in thread
From: Bob Rossi @ 2006-01-23 17:58 UTC (permalink / raw)
  To: David Lamy-Charrier, GDB List

On Mon, Jan 23, 2006 at 12:36:57PM -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 23, 2006 at 06:05:45PM +0100, David Lamy-Charrier wrote:
> > Thanks Daniel for the idea, I am going to try it.
> > 
> > But if I am right, mi_execute_command is called to handle MI commands
> > from the front-end, so it is already too late to execute the commands
> > associated with the breakpoint.
> > The commands should have been executed before and the front-end should
> > even not be notified that GDB stopped and continued, no?
> 
> That would require a much bigger change to the way GDB works.  We've
> been talking about some related changes; the general question is
> whether the MI front end should know that something other than itself
> has caused the inferior to change state.  This is vital to have
> multiple interpreters active at the same time.
> 
> Given how MI works and is defined today, I don't think breakpoint
> commands make a whole lot of sense: your front end should supply the
> commands when it sees the breakpoint.  Is there a reason you can't make
> CDT do that?

I think not allowing this would severaly limit the use of GDB for a lot
of users. People in general already have an entire set of breakpoint
commands written. I don't think it would be a good idea to make the
users translate these commands to a FE specific format, especially 
since each front end would be different.

Bob Rossi


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 17:58           ` Bob Rossi
@ 2006-01-23 19:34             ` Daniel Jacobowitz
  2006-01-24  4:48               ` Jim Ingham
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2006-01-23 19:34 UTC (permalink / raw)
  To: David Lamy-Charrier, GDB List

On Mon, Jan 23, 2006 at 12:53:59PM -0500, Bob Rossi wrote:
> I think not allowing this would severaly limit the use of GDB for a lot
> of users. People in general already have an entire set of breakpoint
> commands written. I don't think it would be a good idea to make the
> users translate these commands to a FE specific format, especially 
> since each front end would be different.

Then what should GDB do?  Treat the command list as CLI commands or
current interpreter commands?  How about the poster's original issue:
should their output come out before the *stopped?  After?  Replacing
it?

That's why I called it presently poorly defined :-)

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: breakpoint commands no more working due to MI front-end
  2006-01-23 19:34             ` Daniel Jacobowitz
@ 2006-01-24  4:48               ` Jim Ingham
  0 siblings, 0 replies; 10+ messages in thread
From: Jim Ingham @ 2006-01-24  4:48 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: David Lamy-Charrier, GDB List

At Apple, we chose to have the breakpoint commands treated as a list  
of CLI commands.  We emit the breakpoint commands output as console  
output from gdb (with the ~"..." form) this way it goes to the gdb  
console in Xcode, which is where we've trained folks to look for it...

Recently, we've also added support in Xcode to do a lot of this, more  
along the lines of what Daniel was suggesting.  So we have log  
actions that are run from Xcode after the stop, and you can tell  
Xcode to continue, etc...  All this requires no support for  
breakpoint commands through the MI, and works quite well.  But still  
if you have complicated tasks you want to perform in the breakpoint  
command (like switch on values in the target or whatever) it is  
useful to write bare gdb commands.  Xcode still allows you to do that  
- though I must admit this is mostly because I had already made it  
work through the MI long before the Xcode guys got around to  
implementing their version.

Anyway, here's how it looks from the mi side:

$ gdb ./gdb
...
(top-gdb) break captured_main
Breakpoint 3 at 0x23a64: file ../../gdb/src/gdb/main.c, line 156.
(top-gdb) commands 3
Type commands for when breakpoint 3 is hit, one per line.
End with a line saying just "end".
 >print argc
 >continue
 >end
(top-gdb) set interpreter mi
-exec-run
~"[Switching to process 6350 local thread 0xf03]\n"
^running
(gdb)
~"$1 = 0"
~"\n"
~"Continuing.\n"
^continuing
*started,reason="breakpoint-command"
GNU gdb 6.3.50.20050815-cvs (Fri Jan 13 22:09:42 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin8.3.0".
No symbol table is loaded.  Use the "file" command.

(gdb)

Note we had to emit "*started" to tell Xcode that the target had  
continued from the breakpoint command.  If there were no "continue"  
in the command, you would have gotten a "*stopped".  The  
"^continuing" is a wart that I put in for the Xcode guys at one  
point.  I even forget why they wanted it now.  The main thing is the  
*started...

All the code to get this working is in the Apple gdb.  Yet another  
thing that would probably be worth working into a form where we could  
submit it back, but sadly I don't see the time in my schedule to do  
this in the next year at least.  But it did take a little head  
scratching to get it all working correctly, so if anybody wants to  
take this on, you might want to glance at that first.

Jim


On Jan 23, 2006, at 9:58 AM, Daniel Jacobowitz wrote:

> On Mon, Jan 23, 2006 at 12:53:59PM -0500, Bob Rossi wrote:
>> I think not allowing this would severaly limit the use of GDB for  
>> a lot
>> of users. People in general already have an entire set of breakpoint
>> commands written. I don't think it would be a good idea to make the
>> users translate these commands to a FE specific format, especially
>> since each front end would be different.
>
> Then what should GDB do?  Treat the command list as CLI commands or
> current interpreter commands?  How about the poster's original issue:
> should their output come out before the *stopped?  After?  Replacing
> it?
>
> That's why I called it presently poorly defined :-)
>
> -- 
> Daniel Jacobowitz
> CodeSourcery


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2006-01-23 19:37 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-23 11:32 breakpoint commands no more working due to MI front-end David Lamy-Charrier
2006-01-23 13:51 ` Daniel Jacobowitz
2006-01-23 15:52   ` David Lamy-Charrier
2006-01-23 17:05     ` Daniel Jacobowitz
2006-01-23 17:37       ` David Lamy-Charrier
2006-01-23 17:47         ` Daniel Jacobowitz
2006-01-23 17:53           ` David Lamy-Charrier
2006-01-23 17:58           ` Bob Rossi
2006-01-23 19:34             ` Daniel Jacobowitz
2006-01-24  4:48               ` Jim Ingham

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox