RE: arm-aout vs arm-elf

[David Korn <dkorn at pixelpower dot com>]

>-----Original Message-----
>From: Quality Quorum [mailto:qqi@world.std.com]
>Sent: 15 October 2001 15:35

>Ok, let us call one default.
>
>It seems reasonable to expect that if did `b xxx', then I will get
>properly printed arguments when break point is hit. If it does not,
>it is a bug.

  On the contrary: if you set a breakpoint on a line, and the breakpoint
only takes effect *after* the line has executed, *that* would be a bug.

  If you set a breakpoint on the start of a function, and yet it has already
executed some of the function when it breaks, *that* would be a bug.  So the
debugger *couldn't* show you the values of the local variables at the very
start of the function, because they simply do not exist until *after* the
function has begun to run.

  You'll find it makes sense if you regard the first 'line' of a function,
the declaration with the return type and incoming arguments, as actually
being a functional line of code, and the effect of executing this line is
to set up a stack frame with named local variables matching the formal
parameters of the function.  Then Gdb behaves exactly as you would expect
it to, according to whether you set your breakpoint on this line or the
line after; and just specifying 'b xxx' by itself means the very start of
the function, not somewhere already in the code.

  Here's a relevant part from the GDB manual, in the section "Examining
data / Program variables"

---------begin quote---------
Warning: Occasionally, a local variable may appear to have the wrong value
at certain points in a function--just after entry to a new scope, and just
before exit. 

You may see this problem when you are stepping by machine instructions. This
is because, on most machines, it takes more than one instruction to set up a
stack frame (including local variable definitions); if you are stepping by
machine instructions, variables may appear to have the wrong values until
the stack frame is completely built. On exit, it usually also takes more
than one machine instruction to destroy a stack frame; after you begin
stepping through that group of instructions, local variable definitions may
be gone.
----------end quote----------

  It could certainly do with a larger and clearer explanation, I agree.

>Second example is compiled by gcc-3.0.1 and it prints correct values,
>first example is compiled by gcc-2.95.3 and it prints garbage, so I
>suppose that it should be considered a bug in gcc-2.95.3.

  Well, as I've explained, it's not printing garbage values, it's more
that it is printing garbage labels when it says those values correspond
to the function args because they don't.... yet.  In 3.0.1 there must be
some workround that folds the prolog into the first line of code, so for it
to be able to display the values correctly, I would guess that someone has
improved gcc to output liveness/register info for the prolog as well as the
function, so that as you enter the prolog it knows the incoming args are
in the regs, and after the stack frame is created it knows they are there.

  Incidentally, it might be relevant to know which version of gdb you're
using.  Is it one that was more-or-less contemporary with 2.95.x, or is it
a more recent one that is up-to-date with whatever debug info 3.0.1 emits 
these days ?

>BTW, I see nothing wrong in stopping before argument copying is
>complete, the only thing to worry about in order to properly print
>arguments will be an ability of gdb to interperet apcs-32.

  It would indeed be useful, and 3.0.1 does seem to offer the best of both
worlds, but it might well be the case that the ability to include liveness
info in the prolog wasn't included in the earlier versions of gdb that
were contemporary with 2.95.x, and so it would have been a bug had gcc
been designed to emit debug info that gdb couldn't understand.


      DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com