Re: backtrace through 'sleep', (1255 and 1253)

[Michael Elizabeth Chastain <mec at shout dot net>]

eza> yes. How did the prologue analyzer changed between 5.3 and now?

The prologue analyzer got refactored, but it looks like basically
the same code.  There's nothing that understands 'xor %ecx, %ecx'
in the 5.3 code.

In 5.3, i386_frame_chain looks for a frameless function.  It has some
simple tests and it doesn't call the prologue analyzer.  If it can't
decide whether the function is frameless or not, then i386_frame_chain
assumes that is framed.  That works for 'sleep'.

In gdb HEAD, i386_frame_chain directly calls the prologue analyzer.
If the prologue analyzer can't handle it, then i386_frame_chain assumes
that is frameless (the code that I quoted).

>From a user point of view, the workaround for today would be:
use the debugging version of glibc, or use the static version of glibc.
I really don't want to ship gdb 6.0 like that but if we don't fix gdb
then I'll write something like that for PROBLEMS.

I looked at the 'abstract interpretation' code in s390-tdep.c.
I think this is the right solution for gdb HEAD.  For gdb 6.0, I think
that shoving 'xor %reg, %reg' into the existing prologue reader is
probably good enough to get us through the release.  I will make a patch
for this later this week if no one beats me to it.

The sinking feeling I have is that this problem will affect a lot
of architectures, not just i386.

Michael C