Reset breakpoint after load?

Reset breakpoint after load?

[Jie Zhang]

Hi,

While testing Blackfin GCC on bare metal using gdb-comm.exp, I found a 
problem, which I don't know if it's a bug of gdb or by design.

gdb-comm.exp sets breakpoints on exit and abort before load. The problem 
is that GDB tries to skip prologue according to what it reads from 
memory, which might contain random data since the executable has not 
been loaded into memory. In my case, sometimes skip_prologue might skip 
one or two more instructions, which happens to be an exception 
instruction and will trap the processor into an exception event loop 
after running the executable before hit the breakpoints.

Currently I change gdb-comm.exp to set breakpoints after load. In this 
way GDB can set breakpoints in the correct addresses and our GCC testing 
runs fine. But Is it a good idea to ask GDB to reset breakpoints after 
load just as we do on connecting to a new target?


Thanks,
Jie

Re: Reset breakpoint after load?

[Dave Korn]

On 19/01/2010 07:36, Jie Zhang wrote:

> gdb-comm.exp sets breakpoints on exit and abort before load. The problem
> is that GDB tries to skip prologue according to what it reads from
> memory, which might contain random data since the executable has not
> been loaded into memory. In my case, sometimes skip_prologue might skip
> one or two more instructions, which happens to be an exception
> instruction and will trap the processor into an exception event loop
> after running the executable before hit the breakpoints.

  Something is wrong here.  Before the inferior is started, gdb should be
looking at the prologue bytes from the executable image file, not the inferior
memory.  Is something going wrong in gdb_comm_file_cmd()?

    cheers,
      DaveK

Re: Reset breakpoint after load?

[Jie Zhang]

On 01/21/2010 06:18 PM, Dave Korn wrote:
> On 19/01/2010 07:36, Jie Zhang wrote:
>
>> gdb-comm.exp sets breakpoints on exit and abort before load. The problem
>> is that GDB tries to skip prologue according to what it reads from
>> memory, which might contain random data since the executable has not
>> been loaded into memory. In my case, sometimes skip_prologue might skip
>> one or two more instructions, which happens to be an exception
>> instruction and will trap the processor into an exception event loop
>> after running the executable before hit the breakpoints.
>
>    Something is wrong here.  Before the inferior is started, gdb should be
> looking at the prologue bytes from the executable image file, not the inferior
> memory.  Is something going wrong in gdb_comm_file_cmd()?
>
Originally gdb_comm_load () did as below:

  1. set breakpoints at abort and exit

  2. target $protocol $targetname

  3. load

At 1, gdb reads from executable image file when analyze prologue. At 2, 
gdb re-set breakpoints according the bytes read from target memory. So 
after 3 we need to re-set breakpoint again.

I have proposed a patch to dejagnu to change the order to

  1. target $protocol $targetname

  2. load

  3. set breakpoints at abort and exit

which has been accepted and committed. But I think it's still a good 
idea to add the breakpoint re-set in GDB after load.


Jie

Re: Reset breakpoint after load?

[Michael Snyder]

Dave Korn wrote:
> On 19/01/2010 07:36, Jie Zhang wrote:
> 
>> gdb-comm.exp sets breakpoints on exit and abort before load. The problem
>> is that GDB tries to skip prologue according to what it reads from
>> memory, which might contain random data since the executable has not
>> been loaded into memory. In my case, sometimes skip_prologue might skip
>> one or two more instructions, which happens to be an exception
>> instruction and will trap the processor into an exception event loop
>> after running the executable before hit the breakpoints.
> 
>   Something is wrong here.  Before the inferior is started, gdb should be
> looking at the prologue bytes from the executable image file, not the inferior
> memory.  Is something going wrong in gdb_comm_file_cmd()?

Dave, Jie,

I don't believe that gdb can tell when the (remote) inferior
is started.  All gdb knows is that target remote is started.
Thus, if we connect to target remote and then load the image,
there is an interval during which gdb will attempt to read
the prologue bytes from un-initialized target memory.

Seems to me, that interval is a bad time to set breakpoints.

Michael

Re: Reset breakpoint after load?

[Daniel Jacobowitz]

On Thu, Jan 21, 2010 at 10:29:06AM -0800, Michael Snyder wrote:
> >On 19/01/2010 07:36, Jie Zhang wrote:
> >
> >>gdb-comm.exp sets breakpoints on exit and abort before load. The problem
> >>is that GDB tries to skip prologue according to what it reads from
> >>memory, which might contain random data since the executable has not
> >>been loaded into memory. In my case, sometimes skip_prologue might skip
> >>one or two more instructions, which happens to be an exception
> >>instruction and will trap the processor into an exception event loop
> >>after running the executable before hit the breakpoints.

I've had this problem on a MIPS target, too.

> I don't believe that gdb can tell when the (remote) inferior
> is started.  All gdb knows is that target remote is started.
> Thus, if we connect to target remote and then load the image,
> there is an interval during which gdb will attempt to read
> the prologue bytes from un-initialized target memory.
> 
> Seems to me, that interval is a bad time to set breakpoints.

The problem isn't just breakpoints set during the interval, but also before
target remote.  We adjust the breakpoints after target remote.

GDB doesn't know whether we're going to need to load.  Maybe it should
be an option to target remote to load automatically?  I don't know,
that's a little strange.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Reset breakpoint after load?

[Jie Zhang]

On 01/22/2010 02:29 AM, Michael Snyder wrote:
> Dave Korn wrote:
>> On 19/01/2010 07:36, Jie Zhang wrote:
>>
>>> gdb-comm.exp sets breakpoints on exit and abort before load. The problem
>>> is that GDB tries to skip prologue according to what it reads from
>>> memory, which might contain random data since the executable has not
>>> been loaded into memory. In my case, sometimes skip_prologue might skip
>>> one or two more instructions, which happens to be an exception
>>> instruction and will trap the processor into an exception event loop
>>> after running the executable before hit the breakpoints.
>>
>> Something is wrong here. Before the inferior is started, gdb should be
>> looking at the prologue bytes from the executable image file, not the
>> inferior
>> memory. Is something going wrong in gdb_comm_file_cmd()?
>
> Dave, Jie,
>
> I don't believe that gdb can tell when the (remote) inferior
> is started. All gdb knows is that target remote is started.
> Thus, if we connect to target remote and then load the image,
> there is an interval during which gdb will attempt to read
> the prologue bytes from un-initialized target memory.
>
> Seems to me, that interval is a bad time to set breakpoints.
>
I agree that that interval is a bad time to set breakpoints. But if GDB 
re-set breakpoints after load, it still can get the breakpoint set at 
the right addresses.


Jie

Re: Reset breakpoint after load?

[Jie Zhang]

On 01/22/2010 05:19 AM, Daniel Jacobowitz wrote:
> On Thu, Jan 21, 2010 at 10:29:06AM -0800, Michael Snyder wrote:
>>> On 19/01/2010 07:36, Jie Zhang wrote:
>>>
>>>> gdb-comm.exp sets breakpoints on exit and abort before load. The problem
>>>> is that GDB tries to skip prologue according to what it reads from
>>>> memory, which might contain random data since the executable has not
>>>> been loaded into memory. In my case, sometimes skip_prologue might skip
>>>> one or two more instructions, which happens to be an exception
>>>> instruction and will trap the processor into an exception event loop
>>>> after running the executable before hit the breakpoints.
>
> I've had this problem on a MIPS target, too.
>
I didn't notice this issue until recently a bug in toolchain linked in 
simulator libc for bare metal executable, which made this issue easily 
happen.

>> I don't believe that gdb can tell when the (remote) inferior
>> is started.  All gdb knows is that target remote is started.
>> Thus, if we connect to target remote and then load the image,
>> there is an interval during which gdb will attempt to read
>> the prologue bytes from un-initialized target memory.
>>
>> Seems to me, that interval is a bad time to set breakpoints.
>
> The problem isn't just breakpoints set during the interval, but also before
> target remote.  We adjust the breakpoints after target remote.
>
> GDB doesn't know whether we're going to need to load.  Maybe it should
> be an option to target remote to load automatically?  I don't know,
> that's a little strange.
>
Yeah, it's a little strange.


Jie

RE: Reset breakpoint after load?

[Paul Koning]

> On 01/22/2010 05:19 AM, Daniel Jacobowitz wrote:
> > On Thu, Jan 21, 2010 at 10:29:06AM -0800, Michael Snyder wrote:
> >>> On 19/01/2010 07:36, Jie Zhang wrote:
> >>>
> >>>> gdb-comm.exp sets breakpoints on exit and abort before load. The
> problem
> >>>> is that GDB tries to skip prologue according to what it reads
from
> >>>> memory, which might contain random data since the executable has
> not
> >>>> been loaded into memory. In my case, sometimes skip_prologue
might
> skip
> >>>> one or two more instructions, which happens to be an exception
> >>>> instruction and will trap the processor into an exception event
> loop
> >>>> after running the executable before hit the breakpoints.
> >
> > I've had this problem on a MIPS target, too.
> >
> I didn't notice this issue until recently a bug in toolchain linked in
> simulator libc for bare metal executable, which made this issue easily
> happen.
> 
> >> I don't believe that gdb can tell when the (remote) inferior
> >> is started.  All gdb knows is that target remote is started.
> >> Thus, if we connect to target remote and then load the image,
> >> there is an interval during which gdb will attempt to read
> >> the prologue bytes from un-initialized target memory.
> >>...

Yes, but... doesn't GDB take read-only data from the executable file
rather than from the target?  If so then it should not matter.  That's
what "set trust-readonly-sections" does.  Or is it off by default?  Turn
it on, that's good for performance anyway.

	paul

Re: Reset breakpoint after load?

[Jie Zhang]

On 01/22/2010 10:15 AM, Paul Koning wrote:
> Yes, but... doesn't GDB take read-only data from the executable file
> rather than from the target?  If so then it should not matter.  That's
> what "set trust-readonly-sections" does.  Or is it off by default?  Turn
> it on, that's good for performance anyway.
>
I just tested this method and confirm that "set trust-readonly-sections 
on" also works. According to the manual, this option is off by default.


Jie

RE: Reset breakpoint after load?

[Paul Koning]

> On 01/22/2010 10:15 AM, Paul Koning wrote:
> > Yes, but... doesn't GDB take read-only data from the executable file
> > rather than from the target?  If so then it should not matter.
> That's
> > what "set trust-readonly-sections" does.  Or is it off by default?
> Turn
> > it on, that's good for performance anyway.
> >
> I just tested this method and confirm that "set
trust-readonly-sections
> on" also works. According to the manual, this option is off by
default.

Right, I noticed that it's set that way.  I have a GDB with local mods
for our embedded system work; one of the mods is to change the default
to "on".  That makes debug much faster and makes sense in any case.
It's very rare to need it to be off.

	paul

Re: Reset breakpoint after load?

[Daniel Jacobowitz]

On Fri, Jan 22, 2010 at 06:46:23AM -0500, Paul Koning wrote:
> Right, I noticed that it's set that way.  I have a GDB with local mods
> for our embedded system work; one of the mods is to change the default
> to "on".  That makes debug much faster and makes sense in any case.
> It's very rare to need it to be off.

It shouldn't be a global option, anyway, or rather most places should
not consult the global option.  Maybe the option itself should be
tristate (on/off/auto).

My hypothesis is that any place which combines code analysis with use
of the symbol table - e.g. most unwinders, and prologue skipping -
should specify that reads from the executable are OK.  If code in the
executable self-modifies in such a way as to make that incorrect, then
it was going to misbehave anyway.

Anyone see a problem with that - or have a suggestion on implementation?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Reset breakpoint after load?

[Michael Snyder]

Paul Koning wrote:
>> On 01/22/2010 10:15 AM, Paul Koning wrote:
>>> Yes, but... doesn't GDB take read-only data from the executable file
>>> rather than from the target?  If so then it should not matter.
>> That's
>>> what "set trust-readonly-sections" does.  Or is it off by default?
>> Turn
>>> it on, that's good for performance anyway.
>>>
>> I just tested this method and confirm that "set
> trust-readonly-sections
>> on" also works. According to the manual, this option is off by
> default.
> 
> Right, I noticed that it's set that way.  I have a GDB with local mods
> for our embedded system work; one of the mods is to change the default
> to "on".  That makes debug much faster and makes sense in any case.
> It's very rare to need it to be off.


We defaulted it to 'off' when first implemented, just to
be conservative.  Haven't heard of it causing any problems
since then, so perhaps it's time to default it to 'on'.