Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)

Pedro Alves
2011-07-01T09:47:06Z

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>


I guess setting a break on "foo" should set a breakpoint
on " ". Or (another user of prologue skipping,)
stepping into a foo() call should only stop on " ".
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