From: Michael Elizabeth Chastain <mec@shout.net>
To: ezannoni@redhat.com
Cc: drow@mvista.com, gdb@sources.redhat.com
Subject: Re: backtrace through 'sleep', (1255 and 1253)
Date: Mon, 04 Aug 2003 16:35:00 -0000 [thread overview]
Message-ID: <200308041634.h74GYxRk003320@duracef.shout.net> (raw)
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
next reply other threads:[~2003-08-04 16:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-04 16:35 Michael Elizabeth Chastain [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-08-02 15:18 Michael Elizabeth Chastain
2003-08-04 15:33 ` Elena Zannoni
2003-08-04 15:36 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200308041634.h74GYxRk003320@duracef.shout.net \
--to=mec@shout.net \
--cc=drow@mvista.com \
--cc=ezannoni@redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).