bfinish writes to random addresses.

>  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

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