From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: fnf@ninemoons.com, gdb-patches@sources.redhat.com
Subject: Re: RFC: Avoid calling XXX_skip_prologue for assembly code
Date: Thu, 11 Oct 2001 15:40:00 -0000 [thread overview]
Message-ID: <3BC61FD7.5040504@cygnus.com> (raw)
In-Reply-To: <np669leuzf.fsf@zwingli.cygnus.com>
> 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.
>
>
> Would you be willing to try gdb.asm/asm-source.exp against a D10V sim
> with this change? I'm pretty sure your change is going to break that
> test. If so, you could fix the failure by changing the test to set
> the breakpoint after the `enter' sequences.
>
> If you can take care of that, and add a comment indicating why
> assembly language is a special case, then I approve of this change.
Can someone confirm/deny this from me:
> 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.
To put it another way, it would mean that for files with no debug info
``break *foo'' and ``break foo'' would have the same affect.
(As they say it is all comming back to me) I think this gets dragged out
and debated regularly. If the two forms are made identical the ability
to selectivly choose the breakpoint behavour is removed.
Does anyone know the motivation behind the patch?
Andrew
next prev parent reply other threads:[~2001-10-11 15:40 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
2001-10-11 14:17 ` Jim Blandy
2001-10-11 15:40 ` Andrew Cagney [this message]
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=3BC61FD7.5040504@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