Re: Breakpoints

Re: Breakpoints

[Mark Salter]

>>>>> Kevin Buettner writes:

> On Dec 22,  2:29pm, David Williams wrote:
>> Does GDB ever need to set more than one breakpoint when stepping through 
>> source code? I have not (as yet) seen this type of behaviour.

> Can the target do a singlestep in hardware or do you have to do
> software emulation?  If the latter, when you're stepping by machine
> instruction, you'd need two breakpoints on a conditional branch;
> one for the branch target, the other for the instruction after the
> branch.

Even in the latter case, the stub can evaluate the condition of the
branch to see which way its going to go.

--Mark

breakpoints

[jacques]

How do I set a breakpoint right after the last expression in a for loop? 
Thanks.
--Jacques

Breakpoints

[Satyavathi Malladi]

Hi,
  I have compiled a program using the gcc compiler with the options -g and
-ax (-ax is the  option to enable block profiling). I am debugging the
program using gdb-5.2 . I set a breakpoint at main. When the program hits
the breakpoint, I obtained the backtrace of the program.It was as follows:
(gdb) bt
#0  main () at ex7.c:7
#1  0x400a5316 in __libc_start_main (main=0x8048a34 <main>, argc=1,
ubp_av=0xbffff594, init=0x80487ac <_init>, fini=0x804a1d0 <_fini>,
rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffff58c)
at ../sysdeps/generic/libc-start.c:129

Then I continued the program using the command "continue". Then the
breakpoint at main was hit again.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08048a50 in main () at ex7.c:7
Then when I tried to obtain the backtrace, I got the following output:
(gdb) bt
#0  0x08048a50 in main () at ex7.c:7
#1  0xbffff568 in ?? ()

Can someone help me figure out why this is happening.

Thanks,
Satya

Re: Breakpoints

[J.T. Conklin]

>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Hi all, Does GDB ever need to set more than one breakpoint when
David> stepping through source code? I have not (as yet) seen this
David> type of behaviour.

I don't know.  It would be useful if GDB only needed one breakpoint.
Yours is not the only target with a single hardware breakpoint.

David> I have a stub that supports breakpoints in flash via hardware
David> facility but it can set only one breakpoint. If GDB requires
David> more than one at time then I am in trouble. My target is
David> 68EZ328 (68000 core, not CPU32, no BDM, has its own peculiar
David> emulation mode). My stub currently looks for attempts to write
David> trap #1 op-codes to program memory (FLASH) and then instead of
David> writing to program memory it sets a hardware breakpoint at the
David> address (thanks Stan for the suggestion).

It might be useful to support the remote protocol's 'Z'/'z' breakpoint
commands.  This eliminates the possibility that a memory write will be
confused with breakpoint insertion.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Wed Dec 22 16:34:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: protocol spec
Date: Wed, 22 Dec 1999 16:34:00 -0000
Message-id: <5mbt7i337b.fsf@jtc.redbacknetworks.com>
References: <Pine.SGI.3.95.991219200735.6636A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00544.html
Content-length: 1533

>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> IMHO, we have to resolve just a few key issues here one way
Quality> or other, before piling new operations into remote protocol.
Quality>
Quality> 1. Do we want the remote to support per thread software
Quality>    breakpoints ?

Absolutly.  At the very least, we don't want to preclude the target
debug agent from supporting per thread breakpoints (of any type).

The model I was thinking of when I originally proposed the breakpoint
extensions was that it would ultimately be up to the agent whether to
implement thread specific breakpoints.  GDB would make no assumptions
--- if a breakpoint fired, it would determine the thread od and would
continue target execution if a breakpoint wasn't set for that thread.

On target with a debug agent that doesn't handle thread specific
breakpoints, you might see a GDB<->debug agent dialog something like:

        -> Hg05
        <- OK
        -> Z0,XXXX,2
        <- OK
        -> c
        <- T05:PC=XXXX;thread=00
        -> c
        <- T05:PC=XXXX;thread=01
        -> c
        <- T05:PC=XXXX;thread=00
        -> c
        <- T05:PC=XXXX;thread=05

But on a system that supports thread specific breakpoints, you'd see
something like this:

        -> Hg05
        <- OK
        -> Z0,XXXX,2
        <- OK
        -> c
        <- T05:PC=XXXX;thread=05

This could be a substantial difference, especially when using low
bandwidth or high latency i/o channels.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Wed Dec 22 17:51:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Stan Shebs is leaving Cygnus
Date: Wed, 22 Dec 1999 17:51:00 -0000
Message-id: <199912230151.RAA24745@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00545.html
Content-length: 1522

Yes, I'm resigning from Cygnus; my last day in the office is tomorrow,
1999-12-23. Yes, this is rather sudden!  The reasons are a little
complicated and I don't want to "overshare" :-), so suffice it to say
that my personal stock situation makes it advisable for me not to be a
Cygnus employee when the Red Hat merger is completed.

The timing is somewhat unfortunate, because I'm still completely
enthusiastic about Cygnus, Red Hat, GDB, GNU, etc, and our little
community's future prospects look brighter than they ever have before.
In fact, once my financial situation allows, I would very much like to
go to work at Red Hat!

In the meantime, I intend to continue working on GDB and to continue
maintaining parts of it, while spreading more of my tasks around to
other people.  RMS has a steering committee proposal that he should be
posting soon, and that will be a good first step in this direction.
The committee can then decide whether it would prefer GDB to keep the
status quo of a single maintainer coordinating sub-maintainers, or to
be more anarchic with no single technical decisionmaker, a la GCC.  In
any case, I'm still planning to serve on this committee.

My temporary mail address will be shebs@nabeng.com, at least until I
pick a cool domain name for my new consulting business. :-) Also, from
25 Dec to 8 Jan, I'm going to be savoring margaritas in the tropics,
and incommunicado during the entire time.  After that, however, I will
be available for tools consulting and contract work.

								Stan
From ovidiu@cup.hp.com Wed Dec 22 18:51:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Stan Shebs is leaving Cygnus 
Date: Wed, 22 Dec 1999 18:51:00 -0000
Message-id: <199912230249.SAA09138@orion.rgv.hp.com>
References: <199912230151.RAA24745@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00546.html
Content-length: 1957

Hi Stan,

I'm terribly sorry to hear this! I was just thinking that you guys at Cygnus
must be really lucky with RedHat these days, given the high stock price it has.
However it appears it's not quite true :-(.

I wish you best of luck in your new enterprise!

Greetings and Merry Christmas,
Ovidiu

On Wed, 22 Dec 1999 17:51:15 -0800, Stan Shebs <shebs@cygnus.com> wrote:

> Yes, I'm resigning from Cygnus; my last day in the office is tomorrow,
> 1999-12-23. Yes, this is rather sudden!  The reasons are a little
> complicated and I don't want to "overshare" :-), so suffice it to say
> that my personal stock situation makes it advisable for me not to be a
> Cygnus employee when the Red Hat merger is completed.
> 
> The timing is somewhat unfortunate, because I'm still completely
> enthusiastic about Cygnus, Red Hat, GDB, GNU, etc, and our little
> community's future prospects look brighter than they ever have before.
> In fact, once my financial situation allows, I would very much like to
> go to work at Red Hat!
> 
> In the meantime, I intend to continue working on GDB and to continue
> maintaining parts of it, while spreading more of my tasks around to
> other people.  RMS has a steering committee proposal that he should be
> posting soon, and that will be a good first step in this direction.
> The committee can then decide whether it would prefer GDB to keep the
> status quo of a single maintainer coordinating sub-maintainers, or to
> be more anarchic with no single technical decisionmaker, a la GCC.  In
> any case, I'm still planning to serve on this committee.
> 
> My temporary mail address will be shebs@nabeng.com, at least until I
> pick a cool domain name for my new consulting business. :-) Also, from
> 25 Dec to 8 Jan, I'm going to be savoring margaritas in the tropics,
> and incommunicado during the entire time.  After that, however, I will
> be available for tools consulting and contract work.
> 
> 								Stan
> 

RE: Breakpoints

[David Williams]

My question is still does GDB need to set more than one breakpoint when 
stepping through source? Thinking about it a little more GDB should have 
all of the information available to decide whether a branch will occur. It 
has the current value of all the registers (esp CCR) so it can work it out 
- the real question is does it use this information?

Dave.

----------
From: 	Mark Salter[SMTP:msalter@cygnus.com]
Sent: 	Thursday, December 23, 1999 2:09 AM
To: 	kevinb@cygnus.com
Cc: 	davidwilliams@ozemail.com.au; gdb@sourceware.cygnus.com
Subject: 	Re: Breakpoints

>>>>> Kevin Buettner writes:

> On Dec 22,  2:29pm, David Williams wrote:
>> Does GDB ever need to set more than one breakpoint when stepping through 
>> source code? I have not (as yet) seen this type of behaviour.

> Can the target do a singlestep in hardware or do you have to do
> software emulation?  If the latter, when you're stepping by machine
> instruction, you'd need two breakpoints on a conditional branch;
> one for the branch target, the other for the instruction after the
> branch.

Even in the latter case, the stub can evaluate the condition of the
branch to see which way its going to go.

--Mark