This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Richard Earnshaw <rearnsha at arm dot com>, Yao Qi <yao at codesourcery dot com>, Terry Guo <Terry dot Guo at arm dot com>
- Date: Fri, 1 Jul 2011 10:46:36 +0100
- Subject: Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)
- References: <000901cc34bc$fd1aa6a0$f74ff3e0$@guo@arm.com> <4E0AF7A6.1040800@codesourcery.com> <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