Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: 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:22:00 -0000	[thread overview]
Message-ID: <np8zeidiyh.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <200110051954.f95JsNn07270@fishpond.ninemoons.com>

[I sent that last reply sooner than I intended.]

Fred Fish <fnf@www.ninemoons.com> writes:
> There is little point in attempting to skip over prologues if we
> already know for a fact that the source language is assembly.
>
> In fact, attempting to do so may actually be incorrect if the user has
> taken the output of the compiler, used that as the basis for his code,
> and hand optimized it in some way to produce an assembly version.
> There could still be prologue code in the hand crafted version.
> 
> Another way to handle this issue would be to have each of the
> "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.

Andrew Cagney pointed out to me that gdb.asm/asm-source.exp actually
does try to get a backtrace from an assembly language function, and
expects to see the right function names.  For that to work, we need to
skip prologues.  But that test may be resting on some questionable
assumptions.

You're right, of course, that GDB really has no basis on which to make
assumptions about how an assembly language function lays out its
frame, or even that a symbol represents a function's entry point.  But
given how common it is to mix C and assembly language, it's also not
entirely unreasonable to ask for a backtrace.

I tend to feel that, if someone wants to see a backtrace out of a
hand-coded assembly function, they can set their breakpoint at the
right place themselves; GDB simply hasn't enough information to do it
for them.

I'm ready to approve this patch, but I think Michael Snyder might be
able to help me think about this more clearly, so I'm waiting for a
call from him.


  parent reply	other threads:[~2001-10-11 13:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-05 12:55 Fred Fish
2001-10-11 13:13 ` Jim Blandy
2001-10-11 13:37   ` Andrew Cagney
2001-10-11 13:22 ` Jim Blandy [this message]
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
     [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-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=np8zeidiyh.fsf@zwingli.cygnus.com \
    --to=jimb@zwingli.cygnus.com \
    --cc=fnf@ninemoons.com \
    --cc=gdb-patches@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