From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Richard Earnshaw <rearnsha@arm.com>,
Yao Qi <yao@codesourcery.com>, Terry Guo <Terry.Guo@arm.com>
Subject: Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)
Date: Fri, 01 Jul 2011 09:47:00 -0000 [thread overview]
Message-ID: <201107011046.36650.pedro@codesourcery.com> (raw)
In-Reply-To: <4E0D8C5B.2090407@arm.com>
On Friday 01 July 2011 09:59:07, Richard Earnshaw wrote:
> On 29/06/11 11:00, Yao Qi wrote:
> > On 06/29/2011 04:47 PM, Terry Guo wrote:
> >> Hi,
> >>
> >> First if you look at the generated binary code, I thought it is a valid case. After performing the function test, it will fall into function bar which is a normal function. At least my case can run correctly on QEMU. It is very likely for people to write program in assembly code like:
> >>
> >> main:
> >> b test
> >>
> >> test:
> >> movs r5, #10
> >> bar:
> >> push.......
> >> .........
> >>
> >
> > We are lucky here GCC places bar next to function test physically, but
> > gcc may also place function test and bar in other layout, like
> >
> > main:
> > b test
> >
> > bar:
> > push ...
> >
> > test:
> > moves r5, #10
> >
> > After test, processor will run some instructions that we don't know.
> > IMO, it is incorrect.
> >
>
> Which is one of the reasons why GCC has the option -fno-toplevel-reorder
> to prevent such reordering.
Indeed. Well, GDB is not a compiler; it is supposed to be able to
debug buggy code. :-) Turning things upside down, the root question is
whether there are valid cases where when setting a breakpoint
at "foo", when GDB goes analysing the prologue, GDB should cross
function boundaries into the next function, which would get
broken by Terry's proposal. E.g., say, foo and bar get merged
by some smart compiler/linker:
foo:
<nop>
bar:
<regular prologue>
<body code>
I guess setting a break on "foo" should set a breakpoint
on "<body code>". Or (another user of prologue skipping,)
stepping into a foo() call should only stop on "<body code>".
Or, should GDB be conservative, and never cross the function
body when skipping the prologue the hard way, and only
cross it if debug info says so.
--
Pedro Alves
next prev parent reply other threads:[~2011-07-01 9:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-27 11:26 Terry Guo
2011-06-29 1:26 ` Terry Guo
2011-06-29 5:36 ` Yao Qi
2011-06-29 7:00 ` Terry Guo
2011-06-29 8:00 ` Yao Qi
2011-06-29 8:49 ` Terry Guo
[not found] ` <45520D6299C11E4588128526465332BB0D0C8B1246@SAROVARA.Asiapac.Arm.com>
2011-06-29 10:00 ` Yao Qi
2011-06-29 10:17 ` Terry Guo
2011-07-01 8:59 ` Richard Earnshaw
2011-07-01 9:47 ` Pedro Alves [this message]
2011-07-13 13:21 ` Terry Guo
-- strict thread matches above, loose matches on Subject: below --
2011-06-24 2:31 Terry Guo
2011-06-24 3:55 ` Yao Qi
2011-06-24 8:59 ` Pedro Alves
2011-06-24 10:39 ` Yao Qi
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=201107011046.36650.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=Terry.Guo@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=rearnsha@arm.com \
--cc=yao@codesourcery.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