Hi,
On Tue, 12 Dec 2006 16:52:33 +0100, Jakub Jelinek wrote:
...
> Here is something that would handle by default same_value retaddr_column:
[ http://sources.redhat.com/ml/gdb/2006-12/msg00100.html ]
Thanks for this backward compatible glibc unwinder patch. I wish to have it
accepted as a step i
Hi,
On Tue, 12 Dec 2006, Ulrich Drepper wrote:
> > Really? Well, that's one interpretation. I don't believe that,
> > though. It's certainly an inconsistency in the specification, which
> > says that null-termination is supported, and this implies that you
> > can't put a zero in there.
>
Hi,
On Mon, 11 Dec 2006, Jan Kratochvil wrote:
> currently (on x86_64) the gdb backtrace does not properly stop at the
> outermost
> frame:
>
> #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
> #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> #5 0x00
Hi,
On Tue, 12 Dec 2006, Andrew Haley wrote:
> > > In practice, %ebp either points to a call frame -- not necessarily
> > > the most recent one -- or is null. I don't think that having an
> > > optional frame pointer mees you can use %ebp for anything random at
> > > all, but we need to m
> Ian Lance Taylor writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > In practice, %ebp either points to a call frame -- not necessarily
> the
> > > most recent one -- or is null. I don't think that having an optional
> > > frame pointer mees you can use %ebp for anything r
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > In practice, %ebp either points to a call frame -- not necessarily the
> > most recent one -- or is null. I don't think that having an optional
> > frame pointer mees you can use %ebp for anything random at all, but we
Andrew Haley <[EMAIL PROTECTED]> writes:
> In practice, %ebp either points to a call frame -- not necessarily the
> most recent one -- or is null. I don't think that having an optional
> frame pointer mees you can use %ebp for anything random at all, but we
> need to make a clarification request
On Tue, Dec 12, 2006 at 03:26:34PM +, Andrew Haley wrote:
> Ulrich Drepper writes:
> > Andrew Haley wrote:
> > > Null-terminating the call stack is too well-established practice to be
> > > changed now.
> >
> > Which does not mean that the mistake should hold people back.
>
> Sure it doe
On Mon, Dec 11, 2006 at 02:40:22PM -0800, Roland McGrath wrote:
> My reading is that the "ABI authoring body" for GNU systems or the
> "compilation system authoring body" for GNU compilers already specifies
> that the default rule is same_value for callee-saves registers (as chosen
> by each partic
On Tue, 12 Dec 2006 16:26:34 +0100, Andrew Haley wrote:
...
> It's certainly an inconsistency in the specification, which says that
> null-termination is supported, and this implies that you can't put a zero in
> there.
I tested now that you can put the zero there for both the libgcc unwinder and
Andrew Haley wrote:
Sure it does. Not breaking things is an excellent reason, probably
one of the the best reasons you can have.
Nothing breaks if the responsible tools are updated in unison.
Really? Well, that's one interpretation. I don't believe that,
though. It's certainly an inconsi
Ulrich Drepper writes:
> Andrew Haley wrote:
> > Null-terminating the call stack is too well-established practice to be
> > changed now.
>
> Which does not mean that the mistake should hold people back.
Sure it does. Not breaking things is an excellent reason, probably
one of the the best r
Andrew Haley wrote:
Null-terminating the call stack is too well-established practice to be
changed now.
Which does not mean that the mistake should hold people back. This is
just one of the mistakes in the x86-64 ABI. It was copied from x86 and
it was wrong there already.
In practice, %
Mark Kettenis writes:
> > Jan Kratochvil writes:
> >
> > > currently (on x86_64) the gdb backtrace does not properly stop at
> > > the outermost frame:
> > >
> > > #3 0x0036ddb0610a in start_thread () from
> > /lib64/tls/libpthread.so.0
> > > #4 0x0036dd0c68c3 in clone
> Jan Kratochvil writes:
>
> > currently (on x86_64) the gdb backtrace does not properly stop at
> > the outermost frame:
> >
> > #3 0x0036ddb0610a in start_thread () from
> /lib64/tls/libpthread.so.0
> > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> > #5 0x
Jan Kratochvil writes:
> currently (on x86_64) the gdb backtrace does not properly stop at
> the outermost frame:
>
> #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
> #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> #5 0x in ?? ()
>
GCC's unwinder doesn't distinguish undefined from same_value, because it
doesn't matter for EH unwinding purposes. Both mean "nothing to be done
for this register". The distinction only matters to informative unwinding
purposes like debugging. I'm not sure why libgcc's unwinder really ought
to c
Hello,
currently (on x86_64) the gdb backtrace does not properly stop at the outermost
frame:
#3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
#4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
#5 0x in ?? ()
Currently it relies only on clearin
18 matches
Mail list logo
