From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>, fnf@ninemoons.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: Avoid calling XXX_skip_prologue for assembly code
Date: Thu, 11 Oct 2001 13:37:00 -0000 [thread overview]
Message-ID: <3BC602EB.1020908@cygnus.com> (raw)
In-Reply-To: <npadyydjd4.fsf@zwingli.cygnus.com>
> "XXX_skip_prologue" functions in the various XXX-tdep.c files do their
>> own checking first to see if the language is assembly, but they don't
>> have easy access to that info, and each of them would have to do
>> something similar to this patch anyway, so it seems more logical to
>> just do the test in one place.
>
>
> This seems like a good idea, but I'm told that Red Hat has an
> (as-of-yet unreleased) port which actually analyzes prologues for
> assembly-language functions. I assume there's some sort of underlying
> ABI that justifies this.
(I'm not sure what is mean by underlying ABI, but anyway.) This is a
hard problem.
gdb/testsuite/gdb.asm/ contains GDB's sole assembler test (sigh). It
works on the assumption that the target is going to treat ``break main''
and ``break *main'' separatly. The latter stepping into the function to
the point were the stack frame is valid. This suggests that the
behavour is pretty entrenched. The d10v has the necessary framework for
the test. A patch for the h8[35]00 was also submitted but got lost in
the paper work.
Anyway, I suspect (is this true?) that this patch would make ``break
vfprintf'' and ``break *vfprintf'' identical. That in turn could mean
that a backtrace from a debug info free file such as libc.a:vfprintf()
might not work.
Andrew
next prev parent reply other threads:[~2001-10-11 13:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-05 12:55 Fred Fish
[not found] ` <fnf@www.ninemoons.com>
2001-10-05 13:58 ` Kevin Buettner
2001-10-27 16:38 ` [RFA] Change auto-solib-add to boolean, add auto-solib-limit Kevin Buettner
2001-10-29 22:14 ` [RFA] Use 1024*1024 for a megabyte, not 1000000 Kevin Buettner
2001-10-30 17:22 ` [RFA] Fix a couple of auto-solib-add problems Kevin Buettner
2001-10-11 13:13 ` RFC: Avoid calling XXX_skip_prologue for assembly code Jim Blandy
2001-10-11 13:37 ` Andrew Cagney [this message]
2001-10-11 13:22 ` Jim Blandy
2001-10-11 14:17 ` Jim Blandy
2001-10-11 15:40 ` Andrew Cagney
2001-10-11 19:23 ` Fred Fish
2002-04-11 16:30 ` Fred Fish
2002-04-12 8:34 ` Fernando Nasser
2002-04-12 9:41 ` Fred Fish
2002-04-12 9:47 ` Fernando Nasser
2001-10-27 12:50 [RFA] Change auto-solib-add to boolean, add auto-solib-limit Fred Fish
2001-10-27 17:01 ` Elena Zannoni
2001-10-28 1:54 ` Eli Zaretskii
2001-10-29 20:35 [RFA] Use 1024*1024 for a megabyte, not 1000000 Fred Fish
2001-10-30 15:35 [RFA] Fix a couple of auto-solib-add problems Fred Fish
2001-10-31 4:02 ` Eli Zaretskii
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=3BC602EB.1020908@cygnus.com \
--to=ac131313@cygnus.com \
--cc=fnf@ninemoons.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@cygnus.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