bfinish writes to random addresses.

bfinish writes to random addresses.

[Greg Law]

Hi list,

When doing a 'finish' command when EBP contains bad values such that gdb 
gets confused about a function's return address, it writes a breakpoint 
into an essentially random point in the inferior's address space.

Should I report a bug, or do we consider it the user's own stupid fault 
if he/she tries to do a 'finish' command when the frame-pointer is invalid?


Cheers,

Greg

-- 
Greg Law, Undo Software                       http://undo-software.com/

Re: bfinish writes to random addresses.

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 04:39:15PM +0100, Greg Law wrote:
> Hi list,
> 
> When doing a 'finish' command when EBP contains bad values such that gdb 
> gets confused about a function's return address, it writes a breakpoint 
> into an essentially random point in the inferior's address space.
> 
> Should I report a bug, or do we consider it the user's own stupid fault 
> if he/she tries to do a 'finish' command when the frame-pointer is invalid?

Well, is there anything better that could be done about it?  I don't
think so.  Finish is going to take you back to whatever GDB thinks the
previous frame is.

Now, of course, GDB shouldn't get confused in the first place.  That's
always worth filing a bug about, although it may be a case of
inadequate debug information or other similar problems out of our
control.

-- 
Daniel Jacobowitz
CodeSourcery

Re: bfinish writes to random addresses.

[Greg Law]

Daniel Jacobowitz wrote:
> On Tue, Jul 25, 2006 at 04:39:15PM +0100, Greg Law wrote:
> 
>>Hi list,
>>
>>When doing a 'finish' command when EBP contains bad values such that gdb 
>>gets confused about a function's return address, it writes a breakpoint 
>>into an essentially random point in the inferior's address space.
>>
>>Should I report a bug, or do we consider it the user's own stupid fault 
>>if he/she tries to do a 'finish' command when the frame-pointer is invalid?
> 
> 
> Well, is there anything better that could be done about it?

I guess one option would be to use a hardware breakpoint when setting 
breakpoints based on such "derived" addresses.  At least that way it's 
non-destructive if gdb gets it wrong.

Having gdb check the return address looks like a sensible code address 
might also be worthwhile.  Of course this will not fix all cases, 
especially if the calculated return address happens to point into the 
middle of an instruction.  But hopefully in reality most things that 
look like pointers to code will actually be pointers to code, and so 
properly aligned, and the breakpoint will just go to the wrong place, 
rather than clobbering random data.

>  I don't
> think so.  Finish is going to take you back to whatever GDB thinks the
> previous frame is.
> 
> Now, of course, GDB shouldn't get confused in the first place.  That's
> always worth filing a bug about, although it may be a case of
> inadequate debug information or other similar problems out of our
> control.

In the particular case I'm looking at I think it's reasonable that gdb 
gets the return address wrong.  It's some assembler code that clobbers 
EBP.  My concern was more gdb's ability to clobber arbitrary inferior 
addresses, and the subtle problems this might lead to.

g


-- 
Greg Law, Undo Software                       http://undo-software.com/

Re: bfinish writes to random addresses.

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 05:01:30PM +0100, Greg Law wrote:
> I guess one option would be to use a hardware breakpoint when setting 
> breakpoints based on such "derived" addresses.  At least that way it's 
> non-destructive if gdb gets it wrong.

Every address where GDB sets any breakpoint is "derived" in that sense.
And there aren't very many hardware breakpoints, if any.

> Having gdb check the return address looks like a sensible code address 
> might also be worthwhile.  Of course this will not fix all cases, 
> especially if the calculated return address happens to point into the 
> middle of an instruction.  But hopefully in reality most things that 
> look like pointers to code will actually be pointers to code, and so 
> properly aligned, and the breakpoint will just go to the wrong place, 
> rather than clobbering random data.

... Properly aligned?  You're talking about %ebp so I assume you're
talking about x86, and instructions have no alignment on this
architecture.

Warning when returning from something with a symbol to something
without a symbol is an interesting suggestion.  Does anyone else have
comments?  Should this warn?

(gdb) bt
#0 foo()
#1 0x4000000 in ???
(gdb) finish

-- 
Daniel Jacobowitz
CodeSourcery

Re: bfinish writes to random addresses.

[Greg Law]

Daniel Jacobowitz wrote:
> On Tue, Jul 25, 2006 at 05:01:30PM +0100, Greg Law wrote:
> 
>>I guess one option would be to use a hardware breakpoint when setting 
>>breakpoints based on such "derived" addresses.  At least that way it's 
>>non-destructive if gdb gets it wrong.
> 
> 
> Every address where GDB sets any breakpoint is "derived" in that sense.

What I meant was if the address comes from looking up a symbol or some 
such, then it seems reasonable to have more confidence in it being 
correct.  As opposed to an address derived from program state -- namely 
function return addresses.

> And there aren't very many hardware breakpoints, if any.

At least in the cases I've seen on x86, most of the time the hardware 
breakpoints aren't in use.  Of course, on other architectures there may 
be none, and on x86 they may all be used.  But my point was that if a 
hardware breakpoint is used if available, it would fix this at least in 
those cases.

Maybe this is considered sufficiently unusual, or a user trying to do 
such a thing is considered sufficiently stupid that it isn't considered 
worth the effort.  But I alas I was sufficiently stupid, and it did take 
quite a while to track down what was going on here.

> 
> 
>>Having gdb check the return address looks like a sensible code address 
>>might also be worthwhile.  Of course this will not fix all cases, 
>>especially if the calculated return address happens to point into the 
>>middle of an instruction.  But hopefully in reality most things that 
>>look like pointers to code will actually be pointers to code, and so 
>>properly aligned, and the breakpoint will just go to the wrong place, 
>>rather than clobbering random data.
> 
> 
> ... Properly aligned?  You're talking about %ebp so I assume you're
> talking about x86, and instructions have no alignment on this
> architecture.

Sorry, bad terminology from me.  What I meant was that if there is a 
word in memory that is an address in a text segment, then chances are it 
is a pointer to some instruction, so most likely it points at the 
beginning of the instruction, not into the middle of an instruction.

> 
> Warning when returning from something with a symbol to something
> without a symbol is an interesting suggestion.  Does anyone else have
> comments?  Should this warn?
> 
> (gdb) bt
> #0 foo()
> #1 0x4000000 in ???
> (gdb) finish
> 

I was actually suggesting an error rather than a warning.  In this case, 
it seems that writing into 0x40000000 is almost certainly not what the 
user wants gdb to be doing.

Greg

-- 
Greg Law, Undo Software                       http://undo-software.com/

Re: bfinish writes to random addresses.

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 05:24:32PM +0100, Greg Law wrote:
> >Warning when returning from something with a symbol to something
> >without a symbol is an interesting suggestion.  Does anyone else have
> >comments?  Should this warn?
> >
> >(gdb) bt
> >#0 foo()
> >#1 0x4000000 in ???
> >(gdb) finish
> >
> 
> I was actually suggesting an error rather than a warning.  In this case, 
> it seems that writing into 0x40000000 is almost certainly not what the 
> user wants gdb to be doing.

Surprisingly often it is.  We need to be sparing with errors.

-- 
Daniel Jacobowitz
CodeSourcery

Re: bfinish writes to random addresses.

[Mark Kettenis]

>  Daniel Jacobowitz wrote:
>
> > And there aren't very many hardware breakpoints, if any.
>
>  At least in the cases I've seen on x86, most of the time the hardware
>  breakpoints aren't in use.  Of course, on other architectures there may
>  be none, and on x86 they may all be used.  But my point was that if a
>  hardware breakpoint is used if available, it would fix this at least in
>  those cases.

If you can come up with some code that doesn't compicate matters too much
and falls back on the software breakpoints if no hardware breakpoints are
available, that might be a good idea.

>  Maybe this is considered sufficiently unusual, or a user trying to do
>  such a thing is considered sufficiently stupid that it isn't considered
>  worth the effort.  But I alas I was sufficiently stupid, and it did take
>  quite a while to track down what was going on here.

Well, I's probably a good idea to look before you jump.  Otherwise you
might land in deep shit! ;-)

>  Sorry, bad terminology from me.  What I meant was that if there is a
>  word in memory that is an address in a text segment, then chances are it
>  is a pointer to some instruction, so most likely it points at the
>  beginning of the instruction, not into the middle of an instruction.

Well, there are quite a few cases where programs execute code outside
the text segment.  GCC for example, creates trampolines on the stack
for nested functions.

A better approach would be to look wheter a page at a particular address
is "executable".  But in general that information is not available to GDB.

> > Warning when returning from something with a symbol to something
> > without a symbol is an interesting suggestion.  Does anyone else have
> > comments?  Should this warn?
> >
> > (gdb) bt
> > #0 foo()
> > #1 0x4000000 in ???
> > (gdb) finish
> >
>
>  I was actually suggesting an error rather than a warning.  In this case,
>  it seems that writing into 0x40000000 is almost certainly not what the
>  user wants gdb to be doing.

This situation can arise easily if only partial debug information is
available.  I think that even a warning would be annoying.

Mark

Re: bfinish writes to random addresses.

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 08:22:20PM +0200, Mark Kettenis wrote:
> >  Daniel Jacobowitz wrote:
> >
> > > And there aren't very many hardware breakpoints, if any.
> >
> >  At least in the cases I've seen on x86, most of the time the hardware
> >  breakpoints aren't in use.  Of course, on other architectures there may
> >  be none, and on x86 they may all be used.  But my point was that if a
> >  hardware breakpoint is used if available, it would fix this at least in
> >  those cases.
> 
> If you can come up with some code that doesn't compicate matters too much
> and falls back on the software breakpoints if no hardware breakpoints are
> available, that might be a good idea.

Fortunately, we already need code to do this sort of thing - and it's
one of those issues that we (at CS) are going to be taking a look at
this year, time permitting.  This is just the reverse of trying to use
a software breakpoint when debugging ROM, and the same approach will
work.

-- 
Daniel Jacobowitz
CodeSourcery