* Thread backtrace termination
@ 2005-07-11 16:21 Jonathan Larmour
2005-07-11 16:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 17+ messages in thread
From: Jonathan Larmour @ 2005-07-11 16:21 UTC (permalink / raw)
To: gdb
After a move from GDB 6.1 to GDB 6.3, something new happens with
backtraces on at least ARM and MIPS, e.g.:
(gdb) bt
#0 breakme () at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/tests/thread_gdb.c:108
#1 0xffffffff80021800 in controller (id=0) at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/tests/thread_gdb.c:155
#2 0xffffffff8002a550 in Cyg_HardwareThread::thread_entry
(thread=0x8003d3b0) at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/src/common/thread.cxx:110
#3 0xffffffff8002a500 in global constructors keyed to cyg_scheduler_start
() at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/src/common/kapi.cxx:1257
#4 0xffffffff8002a500 in global constructors keyed to cyg_scheduler_start
() at
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/kernel/current/src/common/kapi.cxx:1257
Previous frame identical to this frame (corrupt stack?)
(gdb)
The two "global constructors keyed to cyg_scheduler_start" lines are bogus
frame entries, although those also happened with GDB 6.1. The "corrupt
stack" whinge is new, and is treated as an error, including terminating
gdbinit scripts etc.
I tried reverting
<http://sources.redhat.com/ml/gdb-patches/2004-01/msg00104.html>, but that
in itself isn't the issue. I know there were a bunch of other dwarf
unwinder changes for GDB 6.2. But rather than try and explain what I've
already tried to do, I'd be interested if someone could clarify to me what
the termination conditions for a backtrace actually _are_. i.e. as an OS
author, how do I initialise a thread context to persuade GDB to stop when
it reaches the innermost frame. I've tried looking at the glibc sources to
see how its thread support works, but it's rather a twisty maze of
passages, and I don't know whether it would have this problem as well anyway.
One thought I had was if it halted if the saved stack pointer is 0, but
that presents all sorts of problems for OS implementors, unless thread
entry functions must now be written in assembler with knowledge of how GDB
does its unwinding. In trying to create that scenario, I couldn't provoke
it to affect things anyway.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Thread backtrace termination
2005-07-11 16:21 Thread backtrace termination Jonathan Larmour
@ 2005-07-11 16:23 ` Daniel Jacobowitz
2005-07-11 17:52 ` Jonathan Larmour
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Jacobowitz @ 2005-07-11 16:23 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: gdb
On Mon, Jul 11, 2005 at 05:20:55PM +0100, Jonathan Larmour wrote:
> The two "global constructors keyed to cyg_scheduler_start" lines are bogus
> frame entries, although those also happened with GDB 6.1. The "corrupt
> stack" whinge is new, and is treated as an error, including terminating
> gdbinit scripts etc.
This is already changed in CVS.
> I tried reverting
> <http://sources.redhat.com/ml/gdb-patches/2004-01/msg00104.html>, but that
> in itself isn't the issue. I know there were a bunch of other dwarf
> unwinder changes for GDB 6.2. But rather than try and explain what I've
> already tried to do, I'd be interested if someone could clarify to me what
> the termination conditions for a backtrace actually _are_. i.e. as an OS
> author, how do I initialise a thread context to persuade GDB to stop when
> it reaches the innermost frame. I've tried looking at the glibc sources to
> see how its thread support works, but it's rather a twisty maze of
> passages, and I don't know whether it would have this problem as well
> anyway.
In general there's no defined way to do this. If the start routine is
written in assembly, take a look at the example I posted earlier this
year of using dwarf2 unwind information to terminate a backtrace by
marking the return address column as undefined. There's a matching GDB
patch, which was committed to HEAD after 6.3.
For compiler-generated code there's really no useful way to do this.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Thread backtrace termination
2005-07-11 16:23 ` Daniel Jacobowitz
@ 2005-07-11 17:52 ` Jonathan Larmour
2005-07-11 18:19 ` Daniel Jacobowitz
0 siblings, 1 reply; 17+ messages in thread
From: Jonathan Larmour @ 2005-07-11 17:52 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz wrote:
> On Mon, Jul 11, 2005 at 05:20:55PM +0100, Jonathan Larmour wrote:
>
>>The two "global constructors keyed to cyg_scheduler_start" lines are bogus
>>frame entries, although those also happened with GDB 6.1. The "corrupt
>>stack" whinge is new, and is treated as an error, including terminating
>>gdbinit scripts etc.
>
>
> This is already changed in CVS.
Okay. I haven't seen that. It still looks like an error to me in frame.c.
BTW, my other web searches seem to indicate that a fair few (naive) people
are thinking they are having stack corruption because GDB thinks there
might be. That's unfortunate.
>>I'd be interested if someone could clarify to me what
>>the termination conditions for a backtrace actually _are_. i.e. as an OS
>>author, how do I initialise a thread context to persuade GDB to stop when
>>it reaches the innermost frame.
>
> In general there's no defined way to do this. If the start routine is
> written in assembly, take a look at the example I posted earlier this
> year of using dwarf2 unwind information to terminate a backtrace by
> marking the return address column as undefined. There's a matching GDB
> patch, which was committed to HEAD after 6.3.
I've had a search for this and not found anything. I'm probably just not
using the right terms. Do you have a pointer, time frame or some search
terms I can use to pin this down? Thanks.
> For compiler-generated code there's really no useful way to do this.
I guess atleast now I know that, which saves me spending more time.
Wouldn't it make sense to make such a convention though, such as having a
return address of 0?
Alternatively, how about adding a new command that allows you to define a
set of entry point symbol names? People can then put an appropriate list
for themselves or their OS in ~/.gdbinit. Or it can be pre-initialised by
the OS support within GDB if there is one. e.g. nm-linux.h. Here's what
I'm thinking of:
set entry-point-name-list main _start _entry
Although handling mangled symbols and multiple languages might be fun. I'm
not an expert on such things.
Thanks,
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Thread backtrace termination
2005-07-11 17:52 ` Jonathan Larmour
@ 2005-07-11 18:19 ` Daniel Jacobowitz
2005-07-12 18:32 ` Jonathan Larmour
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Jacobowitz @ 2005-07-11 18:19 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: gdb
On Mon, Jul 11, 2005 at 06:52:13PM +0100, Jonathan Larmour wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Jul 11, 2005 at 05:20:55PM +0100, Jonathan Larmour wrote:
> >
> >>The two "global constructors keyed to cyg_scheduler_start" lines are
> >>bogus frame entries, although those also happened with GDB 6.1. The
> >>"corrupt stack" whinge is new, and is treated as an error, including
> >>terminating gdbinit scripts etc.
> >
> >
> >This is already changed in CVS.
>
> Okay. I haven't seen that. It still looks like an error to me in frame.c.
The error is caught in the top level code for the backtrace command;
that effectively downgrades it to a warning and backtrace termination.
> BTW, my other web searches seem to indicate that a fair few (naive) people
> are thinking they are having stack corruption because GDB thinks there
> might be. That's unfortunate.
What else would you suggest? GDB is confused. From its point of view,
the stack _is_ corrupt.
> I've had a search for this and not found anything. I'm probably just not
> using the right terms. Do you have a pointer, time frame or some search
> terms I can use to pin this down? Thanks.
Well, the patch was:
2005-04-08 Daniel Jacobowitz <dan@codesourcery.com>
* dwarf2-frame.c (struct dwarf2_frame_cache): New field
undefined_retaddr.
(dwarf2_frame_cache): Initialize undefined_retaddr.
(dwarf2_frame_this_id): Return an invalid frame ID if
undefined_retaddr.
You can find the discussion and sample use on gdb@ a month or two
earlier.
> >For compiler-generated code there's really no useful way to do this.
>
> I guess atleast now I know that, which saves me spending more time.
>
> Wouldn't it make sense to make such a convention though, such as having a
> return address of 0?
This is basically a convention. You could, I suppose, patch a compiler
to generate it. I'm not sure that would be wise.
> Alternatively, how about adding a new command that allows you to define a
> set of entry point symbol names? People can then put an appropriate list
> for themselves or their OS in ~/.gdbinit. Or it can be pre-initialised by
> the OS support within GDB if there is one. e.g. nm-linux.h. Here's what
> I'm thinking of:
>
> set entry-point-name-list main _start _entry
>
> Although handling mangled symbols and multiple languages might be fun. I'm
> not an expert on such things.
*shrug* maybe.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Thread backtrace termination
2005-07-11 18:19 ` Daniel Jacobowitz
@ 2005-07-12 18:32 ` Jonathan Larmour
2005-07-13 10:35 ` Steven Johnson
0 siblings, 1 reply; 17+ messages in thread
From: Jonathan Larmour @ 2005-07-12 18:32 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz wrote:
> On Mon, Jul 11, 2005 at 06:52:13PM +0100, Jonathan Larmour wrote:
>
>>Daniel Jacobowitz wrote:
>>
>>>On Mon, Jul 11, 2005 at 05:20:55PM +0100, Jonathan Larmour wrote:
>>>
>>>
>>>>The two "global constructors keyed to cyg_scheduler_start" lines are
>>>>bogus frame entries, although those also happened with GDB 6.1. The
>>>>"corrupt stack" whinge is new, and is treated as an error, including
>>>>terminating gdbinit scripts etc.
[snip]
> The error is caught in the top level code for the backtrace command;
> that effectively downgrades it to a warning and backtrace termination.
Ah ok, thanks.
>>BTW, my other web searches seem to indicate that a fair few (naive) people
>>are thinking they are having stack corruption because GDB thinks there
>>might be. That's unfortunate.
>
>
> What else would you suggest? GDB is confused. From its point of view,
> the stack _is_ corrupt.
It's possibly alarmist, but it's no big deal.
> Well, the patch was:[snip]
> You can find the discussion and sample use on gdb@ a month or two
> earlier.
Aha, yes, at
http://sources.redhat.com/ml/gdb-patches/2005-03/msg00047.html and friends.
That seems interesting but somewhat unwieldy, and as you said before,
wouldn't apply to compiler generated code.
>>>For compiler-generated code there's really no useful way to do this.
>>
>>I guess atleast now I know that, which saves me spending more time.
>>
>>Wouldn't it make sense to make such a convention though, such as having a
>>return address of 0?
>
>
> This is basically a convention. You could, I suppose, patch a compiler
> to generate it. I'm not sure that would be wise.
If someone were to come up with an __attribute__ that could be used with
GCC to mark functions to be annotated this way, it might be possible. But
it's beyond me (or at least, beyond what I have time to get up to speed
with) and I doubt anyone else will be that interested. Ho hum.
>>Alternatively, how about adding a new command that allows you to define a
>>set of entry point symbol names? People can then put an appropriate list
>>for themselves or their OS in ~/.gdbinit. Or it can be pre-initialised by
>>the OS support within GDB if there is one. e.g. nm-linux.h. Here's what
>>I'm thinking of:
>>
>>set entry-point-name-list main _start _entry
>>
>>Although handling mangled symbols and multiple languages might be fun. I'm
>>not an expert on such things.
>
>
> *shrug* maybe.
Well, I'm prepared to create a patch to add such a command if people here
think something with that principle would be accepted.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Thread backtrace termination
2005-07-12 18:32 ` Jonathan Larmour
@ 2005-07-13 10:35 ` Steven Johnson
2005-07-13 12:53 ` GDB is stepping past main() Konstantin Karganov
0 siblings, 1 reply; 17+ messages in thread
From: Steven Johnson @ 2005-07-13 10:35 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Daniel Jacobowitz, gdb
Jonathan Larmour wrote:
> Daniel Jacobowitz wrote:
>
>> On Mon, Jul 11, 2005 at 06:52:13PM +0100, Jonathan Larmour wrote:
>>
>>> Daniel Jacobowitz wrote:
>>
[snip]
>>> Alternatively, how about adding a new command that allows you to
>>> define a set of entry point symbol names? People can then put an
>>> appropriate list for themselves or their OS in ~/.gdbinit. Or it can
>>> be pre-initialised by the OS support within GDB if there is one.
>>> e.g. nm-linux.h. Here's what I'm thinking of:
>>>
>>> set entry-point-name-list main _start _entry
>>>
>>> Although handling mangled symbols and multiple languages might be
>>> fun. I'm not an expert on such things.
>>
>>
>>
>> *shrug* maybe.
>
>
> Well, I'm prepared to create a patch to add such a command if people
> here think something with that principle would be accepted.
Instead of a "set" command, which sets an entire list, an "add" and
"delete" command that adds to the list and deletes from the list
respectively would be (in my opinion) more useful, because GDB could
default to the standard entries for a target, and then extra's could be
added to/removed from the list.
set entry-point-list add [name]
set entry-point-list delete [name]
(for example)
Alternatively there could be 2 lists, one full of default which you
usually dont change, and one with user added entries.
set entry-point-name-list-default [list]
set entry-point-name-list-user [list]
By default user would be empty, and would be only set by the user (in a
script or otherwise). So the user could be assured they werent messing
with any defaults they didnt want to change.
or the like.
supporting wildcards might also be useful, such as:
set entry-point-list add thread_*
or
set entry-point-list delete *
so if a programmer had a convention of calling all their threads
"thread_blah" they wouldnt have to explicitly name them all, back trace
would terminate at any function with that naming convention.
Just some suggestions, if you are going to do this. My opinion is such
a feature would be worthwhile. If the information can not be easily
provided (or at all) from debug symbols, it would seem highly desirable
to have a manual method of inserting the information.
Steven
^ permalink raw reply [flat|nested] 17+ messages in thread
* GDB is stepping past main()
2005-07-13 10:35 ` Steven Johnson
@ 2005-07-13 12:53 ` Konstantin Karganov
2005-07-13 13:05 ` Daniel Jacobowitz
0 siblings, 1 reply; 17+ messages in thread
From: Konstantin Karganov @ 2005-07-13 12:53 UTC (permalink / raw)
To: gdb
Hello, all.
Why doesn't gdb stop at the main() end and continues to step further?
Ok, it's not a big problem for human, but what should the frontend
debugger do with unknown functions w/o source file positions?
Test case: gcc 3.2.2 and gdb 6.3 on RH Linux, session log here:
(gdb) br main
Breakpoint 1 at 0x8048618: file tmp.cpp, line 7.
(gdb) run
Starting program: /home/kostik/Work/a.out
Breakpoint 1, main (argc=1, argv=0xbffff2f4) at tmp.cpp:7
7 cout<<" Hello world! "<<endl;
(gdb) l
2
3 using namespace std;
4
5 int main(int argc,char* argv[])
6 {
7 cout<<" Hello world! "<<endl;
8 }
9
(gdb) step
Hello world!
8 }
(gdb) step
0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) step
Single stepping until exit from function __libc_start_main,
which has no line number information.
Program exited normally.
(gdb)
What the hell "__libc_start_main" is doing here?
The same happens using "next" instead of "step" and when using a MI
interface...
Best regards,
Konstantin.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB is stepping past main()
2005-07-13 12:53 ` GDB is stepping past main() Konstantin Karganov
@ 2005-07-13 13:05 ` Daniel Jacobowitz
2005-07-13 13:31 ` Konstantin Karganov
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Jacobowitz @ 2005-07-13 13:05 UTC (permalink / raw)
To: Konstantin Karganov; +Cc: gdb
On Wed, Jul 13, 2005 at 04:38:54PM +0400, Konstantin Karganov wrote:
> Hello, all.
>
> Why doesn't gdb stop at the main() end and continues to step further?
> Ok, it's not a big problem for human, but what should the frontend
> debugger do with unknown functions w/o source file positions?
Because the user (in your example) has asked it to step out of main.
You might want to examine global state now that the program is mostly
finished. Or you might want to debug glibc.
If you want to handle this in a debugger, try detecting when you're in
main, step, are no longer in main, and main is no longer in the
backtrace.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB is stepping past main()
2005-07-13 13:05 ` Daniel Jacobowitz
@ 2005-07-13 13:31 ` Konstantin Karganov
2005-07-13 13:39 ` Nathan J. Williams
2005-07-13 13:46 ` Daniel Jacobowitz
0 siblings, 2 replies; 17+ messages in thread
From: Konstantin Karganov @ 2005-07-13 13:31 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> Because the user (in your example) has asked it to step out of main.
I asked to step and started waiting for the program termination message.
And get that stopped somewhere "don't know where"...
> If you want to handle this in a debugger, try detecting when you're in
> main, step, are no longer in main, and main is no longer in the
> backtrace.
Don't you think all this detecting is a debugger's task???
Or else it turns out that the "step" in gdb is broken and has no
defined semantics and needs to be carefully controlled from outside
(whether it made the stepping or not and where it happened to stop)!
And all this "detecting" and outside patches-workarounds are very ugly
solution :(
Working with GDB MI itself is finding the way in the dark, and such
"surprises" like broken commands doesn't rise gdb in users eyes at all...
Best regards,
Konstantin.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB is stepping past main()
2005-07-13 13:31 ` Konstantin Karganov
@ 2005-07-13 13:39 ` Nathan J. Williams
2005-07-13 13:47 ` Konstantin Karganov
2005-07-13 13:46 ` Daniel Jacobowitz
1 sibling, 1 reply; 17+ messages in thread
From: Nathan J. Williams @ 2005-07-13 13:39 UTC (permalink / raw)
To: Konstantin Karganov; +Cc: Daniel Jacobowitz, gdb
Konstantin Karganov <kostik@ispras.ru> writes:
> > Because the user (in your example) has asked it to step out of main.
> I asked to step and started waiting for the program termination message.
> And get that stopped somewhere "don't know where"...
>
> > If you want to handle this in a debugger, try detecting when you're in
> > main, step, are no longer in main, and main is no longer in the
> > backtrace.
> Don't you think all this detecting is a debugger's task???
>
> Or else it turns out that the "step" in gdb is broken and has no
> defined semantics and needs to be carefully controlled from outside
> (whether it made the stepping or not and where it happened to stop)!
"step" is a command that's closely linked to the notion of a source
code line. When you're outside of the region where you have source
(such as the startup code around main()), you're in less-defined
territory.
You might find the "stepi" command better suits your needs, though I'm
not at all sure from your messages what, exactly, you think is
supposed to happen.
- Nathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB is stepping past main()
2005-07-13 13:31 ` Konstantin Karganov
2005-07-13 13:39 ` Nathan J. Williams
@ 2005-07-13 13:46 ` Daniel Jacobowitz
2005-07-13 13:57 ` Konstantin Karganov
2005-07-14 14:27 ` MI *stopped reason Konstantin Karganov
1 sibling, 2 replies; 17+ messages in thread
From: Daniel Jacobowitz @ 2005-07-13 13:46 UTC (permalink / raw)
To: Konstantin Karganov; +Cc: gdb
On Wed, Jul 13, 2005 at 05:17:01PM +0400, Konstantin Karganov wrote:
>
> > Because the user (in your example) has asked it to step out of main.
> I asked to step and started waiting for the program termination message.
> And get that stopped somewhere "don't know where"...
>
> > If you want to handle this in a debugger, try detecting when you're in
> > main, step, are no longer in main, and main is no longer in the
> > backtrace.
> Don't you think all this detecting is a debugger's task???
As a user, I would prefer the debugger not silently run my program to
completion during a "step" command, when issued from a location with
source level debugging information. You're the first person I can ever
recall complaining about this behavior.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB is stepping past main()
2005-07-13 13:39 ` Nathan J. Williams
@ 2005-07-13 13:47 ` Konstantin Karganov
2005-07-13 13:50 ` Dave Korn
0 siblings, 1 reply; 17+ messages in thread
From: Konstantin Karganov @ 2005-07-13 13:47 UTC (permalink / raw)
To: Nathan J. Williams; +Cc: Daniel Jacobowitz, gdb
> You might find the "stepi" command better suits your needs, though I'm
> not at all sure from your messages what, exactly, you think is
> supposed to happen.
I suppose that the program execution starts when main() starts and ends
when main() ends (though in c++ it is not exactly so).
And thus I suppose the debugging to start at the main() beginning and stop
when main() finishes.
The code above main do not exist for me.
Stepping past the end of main should report the program exit.
Best regards,
Konstantin.
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: GDB is stepping past main()
2005-07-13 13:47 ` Konstantin Karganov
@ 2005-07-13 13:50 ` Dave Korn
0 siblings, 0 replies; 17+ messages in thread
From: Dave Korn @ 2005-07-13 13:50 UTC (permalink / raw)
To: 'Konstantin Karganov', 'Nathan J. Williams'
Cc: 'Daniel Jacobowitz', gdb
----Original Message----
>From: Konstantin Karganov
>Sent: 13 July 2005 14:32
>> You might find the "stepi" command better suits your needs, though I'm
>> not at all sure from your messages what, exactly, you think is
>> supposed to happen.
> I suppose that the program execution starts when main() starts and ends
> when main() ends
Wrong. The program does stuff both before and after main().
> The code above main do not exist for me.
Wrong. It's often vital to debug the initiation and termination code.
> Stepping past the end of main should report the program exit.
Wrong. The program has not yet exited, so gdb should not report it.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB is stepping past main()
2005-07-13 13:46 ` Daniel Jacobowitz
@ 2005-07-13 13:57 ` Konstantin Karganov
2005-07-14 14:27 ` MI *stopped reason Konstantin Karganov
1 sibling, 0 replies; 17+ messages in thread
From: Konstantin Karganov @ 2005-07-13 13:57 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> As a user, I would prefer the debugger not silently run my program to
> completion during a "step" command, when issued from a location with
> source level debugging information. You're the first person I can ever
> recall complaining about this behavior.
As the default stepping mode is "step-mode off" (do not enter the
functions w/o debug info) I suppose that the current position is always in
user source code and the FE debugger can display it.
But when stepping at the end of main() this assumption fails - no matter
what is the current step-mode, the debugger gets to the place where it
can't report the current position.
I suppose that the step-mode should affect this behavior also.
Best regards,
Konstantin.
^ permalink raw reply [flat|nested] 17+ messages in thread
* MI *stopped reason
2005-07-13 13:46 ` Daniel Jacobowitz
2005-07-13 13:57 ` Konstantin Karganov
@ 2005-07-14 14:27 ` Konstantin Karganov
2005-07-14 14:40 ` Bob Rossi
2005-07-14 15:15 ` Incorrect breakpoint diagnostics in MI Konstantin Karganov
1 sibling, 2 replies; 17+ messages in thread
From: Konstantin Karganov @ 2005-07-14 14:27 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Hello.
When the execution of the debuggee stops the debugger reports the result
as "*stopped, reason='...' ". I'd like to know if the reason should always
be specified, or not.
Currently, there are cases when the reason is missing (for example, when
stopped on a temporary breakpoint).
Best regards,
konstantin.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MI *stopped reason
2005-07-14 14:27 ` MI *stopped reason Konstantin Karganov
@ 2005-07-14 14:40 ` Bob Rossi
2005-07-14 15:15 ` Incorrect breakpoint diagnostics in MI Konstantin Karganov
1 sibling, 0 replies; 17+ messages in thread
From: Bob Rossi @ 2005-07-14 14:40 UTC (permalink / raw)
To: Konstantin Karganov; +Cc: Daniel Jacobowitz, gdb
On Thu, Jul 14, 2005 at 06:12:55PM +0400, Konstantin Karganov wrote:
> Hello.
>
> When the execution of the debuggee stops the debugger reports the result
> as "*stopped, reason='...' ". I'd like to know if the reason should always
> be specified, or not.
> Currently, there are cases when the reason is missing (for example, when
> stopped on a temporary breakpoint).
I believe the reason should always be specified. Although there is no MI
standard that states it, right? If you know where to add the reason in
breakpoint.c simply add a new enumeration to
mi/mi-command.h:async_reply_reason.
Without the reason, the front end is left a little confused as to what
happened.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 17+ messages in thread
* Incorrect breakpoint diagnostics in MI
2005-07-14 14:27 ` MI *stopped reason Konstantin Karganov
2005-07-14 14:40 ` Bob Rossi
@ 2005-07-14 15:15 ` Konstantin Karganov
1 sibling, 0 replies; 17+ messages in thread
From: Konstantin Karganov @ 2005-07-14 15:15 UTC (permalink / raw)
To: gdb
Hello.
Playing with MI breakpoint commands I found the following thing:
Only "-break-after" and "-break-condition" correctly report the error if
the breakpoint doesn't exist. While other commands report "^done".
(gdb)
-break-after 123 123
&"No breakpoint number 123.\n"
^error,msg="No breakpoint number 123."
(gdb)
-break-enable 123
~"No breakpoint number 123.\n"
^done
(gdb)
-break-disable 123
~"No breakpoint number 123.\n"
^done
(gdb)
-break-delete 123
~"No breakpoint number 123.\n"
^done
The diagnostics goes to console output, that is possibly not visible to FE
user and the result itself is "ok".
Is it a bug?
Best reagards,
Konstantin.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-07-14 15:15 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-11 16:21 Thread backtrace termination Jonathan Larmour
2005-07-11 16:23 ` Daniel Jacobowitz
2005-07-11 17:52 ` Jonathan Larmour
2005-07-11 18:19 ` Daniel Jacobowitz
2005-07-12 18:32 ` Jonathan Larmour
2005-07-13 10:35 ` Steven Johnson
2005-07-13 12:53 ` GDB is stepping past main() Konstantin Karganov
2005-07-13 13:05 ` Daniel Jacobowitz
2005-07-13 13:31 ` Konstantin Karganov
2005-07-13 13:39 ` Nathan J. Williams
2005-07-13 13:47 ` Konstantin Karganov
2005-07-13 13:50 ` Dave Korn
2005-07-13 13:46 ` Daniel Jacobowitz
2005-07-13 13:57 ` Konstantin Karganov
2005-07-14 14:27 ` MI *stopped reason Konstantin Karganov
2005-07-14 14:40 ` Bob Rossi
2005-07-14 15:15 ` Incorrect breakpoint diagnostics in MI Konstantin Karganov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).