Re: What's with all the Cisco stuff?

Stan Shebs
1999-08-13T15:08:00Z

Date: Fri, 13 Aug 1999 08:13:33 -0500
From: William Gatliff <gatliff@haulpak.com>

> I would ecstatic with more interest and input here. "RTOS support" is
> an area where GDB gets hammered relative to its competition, and
> display of kernel objects is a specific feature that gets comes up
> frequently.

On the embedded side, could RTOS support be made a stub issue, instead of a
gdb issue? As an embedded developer, I find it much easier to add/modify a
stub than to muck around with the internals of gdb itself.

If there were a standard set of RDP messages that could be used to deliver
OS information from a stub back to gdb, then I would be happy to add stub
support for my own RTOS, whatever that happens to be, using the RTOS's
native calls.

That was kicked around a bit in our internal (ahem :-) ) discussion.
Basically you ask the RTOS "what kinda objects you got?", get back a list
of types, then ask "how should type X be displayed?" and get back
something like a printf format string or maybe even a bit of XML,
then GDB follows instructions when getting the objects' data and
displaying it.

eCos and other folks observed that this was probably too heavyweight
to impose on every RTOS, although it would make sense for the larger
OSes. Also, you still have the dumpfile problem that JT alluded to,
where you don't necessarily have a live target to run a stub. So
while it would be preferable to put OS-specific bits on the target
side, the design needs to accommodate the possibility that all the
IQ is living on the host somewhere.

Stan
From jtc@redback.com Fri Aug 13 16:49:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: Code in can_use_hardware_watchpoint()
Date: Fri, 13 Aug 1999 16:49:00 -0000
Message-id: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00168.html
Content-length: 1164

I believe the enclosed code from can_use_hardware_watchpoint() has a
problem, but I'm unsure of the proper fix.

The problem is that a expression containing a register variable will
not cause this function to fail (return 0). This seems to result in
GDB forging ahead and placing a hardware watchpoint at a random
address for the register variable. An example of this is something
like 'watch mem[reg] != 0'.

/* Make sure all the intermediate values are in memory. Also make sure
we found at least one memory expression. Guards against watch 0x12345,
which is meaningless, but could cause errors if one tries to insert a
hardware watchpoint for the constant expression. */
for (; v; v = v->next)
{
if (v->lval == lval_memory)
{
if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (TYPE_LENGTH (VALUE_TYPE (v))))
found_memory_cnt++;
}
else if (v->lval != not_lval && v->modifiable == 0)
return 0;
}

One solution is to add an:

else if (v->lval == lval_register)
return 0;

But I'm wondering if instead the v->modifiable == 0 should be == 1
instead.

--jtc

--
J.T. Conklin
RedBack Networks
From eliz@gnu.org Sun Aug 15 05:34:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: gdb@sourceware.cygnus.com
Cc: jtc@redback.com (J.T. Conklin)
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Sun, 15 Aug 1999 05:34:00 -0000
Message-id: <199908151234.IAA14013@mescaline.gnu.org>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00169.html
Content-length: 730

From: jtc@redback.com (J.T. Conklin)
Date: 13 Aug 1999 16:49:25 -0700

> I believe the enclosed code from can_use_hardware_watchpoint() has a
> problem, but I'm unsure of the proper fix.

As long as we are talking about this function, here's another
question: shouldn't the loop below return zero as soon as the first
value is found on the value chain that is NOT okay to watch (as the
macro TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT says)?

for (; v; v = v->next)
{
if (v->lval == lval_memory)
{
if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (TYPE_LENGTH (VALUE_TYPE (v))))
found_memory_cnt++;
}
else if (v->lval != not_lval && v->modifiable == 0)
return 0;
}
From jimb@cygnus.com Sun Aug 15 23:28:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Sun, 15 Aug 1999 23:28:00 -0000
Message-id: <np907cutnd.fsf@zwingli.cygnus.com>
References: <199908132135.OAA19734@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00170.html
Content-length: 1974

As long as we're talking about philosophy...

I agree very much with Stan that GDB should be a bag of tools that
just works, without getting fussy about exactly which features you
configured in, and which you left out. I come closest to throwing a
tantrum when I have to struggle with my debugger while debugging
something else, under a deadline. And I'm on Cygnus's GDB team ---
what's it like for someone else?

However, I am concerned about the approach described here, which I
suspect is really at the heart of JT's concerns:

Ultimately I'd like to see more modularity for system-specific
bits, but we're not there yet, and I don't want to see users
switching to other debuggers because we're waiting for somebody to
write more elegant code.

I read this as, "We will integrate features people want even if they
are non-modular. Doing them in a modular way takes too much time.
We'll get around to it eventually."

I don't think this approach is long-term sustainable. We don't need
modularity because it's beautiful --- we need modularity because,
although we are under deadlines now, we will also be under deadlines a
year from now. Or two years from now.

Beauty and modularity are different. GDB's processor architecture
interface (pre multi-arch) is modular, but not beautiful. We support,
what, twenty different processors? But clearly, you can work on GDB
without knowing them all. So that's a successful structuring.

The problem with the Cisco changes is that they're just sort of mixed
in with the remote stuff (among other things), which ought to be
staying really simple. When I want to understand how remote.c works,
I need to read the Cisco stuff just to reassure myself that it isn't
relevant. Is everyone prepared to jump into remote.c for a contract,
now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)?

I don't have specific ideas for how to fix this, though. But I do
think JT's identified a real problem.
From ac131313@cygnus.com Sun Aug 15 23:47:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Stan Shebs <shebs@cygnus.com>, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Sun, 15 Aug 1999 23:47:00 -0000
Message-id: <37B7B399.714F00DC@cygnus.com>
References: <199908132135.OAA19734@andros.cygnus.com> <np907cutnd.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00171.html
Content-length: 770

Jim Blandy wrote:

> The problem with the Cisco changes is that they're just sort of mixed
> in with the remote stuff (among other things), which ought to be
> staying really simple. When I want to understand how remote.c works,
> I need to read the Cisco stuff just to reassure myself that it isn't
> relevant. Is everyone prepared to jump into remote.c for a contract,
> now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)?

Just to expand on this a little. Two things caused remote.c to expand.
The more important one was that I recommending to Elena that a patch
adding the targets ``async'' and ``extended-async'' be committed.

In the future those targets will be absorbed into more familar
``remote'' and ``extended-remote''.

enjoy,
Andrew
From jimb@cygnus.com Sun Aug 15 23:50:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Temporary breakpoints
Date: Sun, 15 Aug 1999 23:50:00 -0000
Message-id: <np7lmwusmm.fsf@zwingli.cygnus.com>
References: <199908120252.TAA25463@elmo.cygnus.com>
X-SW-Source: 1999-q3/msg00172.html
Content-length: 1484

> I have a question regarding temporary breakpoints...
>
> Under what circumstances should a temporary breakpoint be deleted?

It should be deleted under the same circumstances in which GDB tells
the user it has been hit. A temporary breakpoint is a user-visible
construct (unlike many breakpoints in GDB), so its behavior must be
consistent from the user's point of view.

GDB does not report a breakpoint hit if it occurs exactly when GDB
would have stopped stepping anyway. So, if you set a breakpoint on
the first instruction of a line, and "step" to it, GDB won't report a
hit, because it would have stopped there anyway. If you set a
breakpoint on an instruction in the middle of the line, GDB will
report it, because you've stopped in an unusual place. But if you
stepi, then GDB will never report a breakpoint hit.

It's worth noting that a breakpoint's behavior depends on its intended
use. Breakpoints which GDB uses to implement some internal feature
should behave differently from user-level breakpoints. For example,
the breakpoint which GDB uses to tell when a new shared library has
been loaded should be considered "hit" even if you reach it via stepi,
or even if the user has set another breakpoint on top of it ---
otherwise, GDB will miss the event it was waiting for.

This is what that hairy, worthless table in bpstat_what is all about.
Note that the whole table could be replaced by a call to `max' and a
little logic, if someone wants to take the time.
From jimb@cygnus.com Mon Aug 16 00:04:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Mon, 16 Aug 1999 00:04:00 -0000
Message-id: <np672gury4.fsf@zwingli.cygnus.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00173.html
Content-length: 640

I'm not really familiar with this code, but:

> One solution is to add an:
>
> else if (v->lval == lval_register)
> return 0;

I think this is the right thing.

The value chain is supposed to be a list of all the values generated
while evaluating the watchpoint's expression. (What if someone else
generates a value in the mean time? Don't you think it's a bad idea
to draft a list intended for storage management into use in expression
analysis? Bleah.) If you find anything on there that could change,
but can't be watched, you should return zero.

But the fix seems so obvious there must be something else going on...
From law@cygnus.com Mon Aug 16 00:40:00 1999
From: "Jeffrey A. Law" <law@cygnus.com>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Mon, 16 Aug 1999 00:40:00 -0000
Message-id: <199908160740.AAA18545@rtl.cygnus.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> <np672gury4.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00174.html
Content-length: 1483

In article < np672gury4.fsf@zwingli.cygnus.com > you write:
>I'm not really familiar with this code, but:
>
>> One solution is to add an:
>>
>> else if (v->lval == lval_register)
>> return 0;
>
>I think this is the right thing.
>
>The value chain is supposed to be a list of all the values generated
>while evaluating the watchpoint's expression. (What if someone else
>generates a value in the mean time? Don't you think it's a bad idea
>to draft a list intended for storage management into use in expression
>analysis? Bleah.) If you find anything on there that could change,
>but can't be watched, you should return zero.
I agree with Jim (and I am somewhat familiar with the code, though most
of the details have become fuzzy over the years).

Basically we have to build a list of all the expressions/values which
are required to evaluate a watchpoint. If anything on that list of
values can not be watched with a hardware watchpoint, then we do not
allow hardware watchpoints to be used.

>But the fix seems so obvious there must be something else going on...
I don't think so. I think it's just a case we didn't properly think
through.

If the only value on the chain was a reg, then we'd be OK because we would
not have found a memory location. But if we try to watch p->q and P is in
a reg, then we'd lose.

At one time that code may have done an "else return 0;", but that may have
been kicking out too many things which it should have accepted.

jeff
From wmann@avici.com Mon Aug 16 06:17:00 1999
From: Bill Mann <wmann@avici.com>
To: Jim Blandy <jimb@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Temporary breakpoints
Date: Mon, 16 Aug 1999 06:17:00 -0000
Message-id: <4.1.19990816090334.00c4fd70@mailhost.avici.com>
References: <Kevin> <Buettner's> <message> <of> <Wed,> <11> <Aug> <1999> <19:52:45> <-0700> <(PDT)> <199908120252.TAA25463@elmo.cygnus.com> <np7lmwusmm.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00175.html
Content-length: 2222

At 01:49 AM 8/16/99 -0500, Jim Blandy wrote:
>
>> I have a question regarding temporary breakpoints...
>>
>> Under what circumstances should a temporary breakpoint be deleted?
>
>It should be deleted under the same circumstances in which GDB tells
>the user it has been hit. A temporary breakpoint is a user-visible
>construct (unlike many breakpoints in GDB), so its behavior must be
>consistent from the user's point of view.

Right!

>GDB does not report a breakpoint hit if it occurs exactly when GDB
>would have stopped stepping anyway. So, if you set a breakpoint on
>the first instruction of a line, and "step" to it, GDB won't report a
>hit, because it would have stopped there anyway. If you set a
>breakpoint on an instruction in the middle of the line, GDB will
>report it, because you've stopped in an unusual place. But if you
>stepi, then GDB will never report a breakpoint hit.

But I think that's not the way it should work. If I set a breakpoint, then
step over it, I want the breakpoint to be hit. I want it to print what it
would normally print, or count if it's a multiple proceed, or execute
special commands if they are defined. I see a breakpoint as a temporary
patch to my program, and I want single step to honor that patch (as a unit).

>It's worth noting that a breakpoint's behavior depends on its intended
>use. Breakpoints which GDB uses to implement some internal feature
>should behave differently from user-level breakpoints. For example,
>the breakpoint which GDB uses to tell when a new shared library has
>been loaded should be considered "hit" even if you reach it via stepi,
>or even if the user has set another breakpoint on top of it ---
>otherwise, GDB will miss the event it was waiting for.

But what's different about internal breakpoints? All breakpoints should
work like this. If there are several breakpoints at the same location,
they should all be executed, one after the other, but only return
interactive control to the user if one or more of them don't 'continue'.

>This is what that hairy, worthless table in bpstat_what is all about.
>Note that the whole table could be replaced by a call to `max' and a
>little logic, if someone wants to take the time.