Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Greg Law <glaw@undo-software.com>
To: Daniel Jacobowitz <drow@false.org>,  gdb@sourceware.org
Subject: Re: bfinish writes to random addresses.
Date: Tue, 25 Jul 2006 16:27:00 -0000	[thread overview]
Message-ID: <44C645C0.1050409@undo-software.com> (raw)
In-Reply-To: <20060725160914.GA14110@nevyn.them.org>

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/


  reply	other threads:[~2006-07-25 16:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-25 15:41 Greg Law
2006-07-25 15:42 ` Daniel Jacobowitz
2006-07-25 16:09   ` Greg Law
2006-07-25 16:20     ` Daniel Jacobowitz
2006-07-25 16:27       ` Greg Law [this message]
2006-07-25 16:53         ` Daniel Jacobowitz
2006-07-25 18:40         ` Mark Kettenis
2006-07-26  1:21           ` Daniel Jacobowitz

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=44C645C0.1050409@undo-software.com \
    --to=glaw@undo-software.com \
    --cc=drow@false.org \
    --cc=gdb@sourceware.org \
    /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