Re: breakpoint extension for remote protocol, take II

[jtc@redback.com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> I was unaware processors with multiple software breakpoints
>> existed.  I assume that the 2 byte breakpoint instructions have to
>> be inserted in "high-density" code segments and 4 byte breakpoints
>> insns have to be inserted in "low-density" segments.
>>
>> We can almost get away without specifying breakpoint types.  Since
>> in most cases the stub is bound into the executable, thus can
>> determine whether the breakpoint is within a high or low density
>> code segment.  However, this would not be suitable for applications
>> like monitors with a remote protocol front end, as those would not
>> have any prior knowledge of an arbitrary program's memory map.

Andrew> FYI, I can't see how a stub can determine the breakpoint
Andrew> size/type from just the address.  As it is GDB has enough
Andrew> trouble - in the case of the ARM, GDB ends up using symbol
Andrew> table information.

I was thinking of a situation where the linker script adds special
symbols at the beginning and end of the high and low density code
segments, and the stub compares the breakpoint address with those
symbols.  This will work in a self contained executable, but not if
any code is loaded dynamically.

Andrew> I've also been doing some research into the ``B'' and ``b''
Andrew> packets.  While the stubs found in gdb/*stub.c don't support
Andrew> ``b'' or any other ``B'' packet there are other stubs (non
Andrew> GPL'd) that do reconize it :-(

Bleh.  But that's what the 'q' escape is for.  IMO, all experimental
protocol extensions should be using 'q'; likewise, GDB should never
use 'q' itself.  But since GDB uses 'q', a stub using 'B' or 'b' is
not surprising.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Mon Jun 14 16:51:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Testsuite Organization Proposal
Date: Mon, 14 Jun 1999 16:51:00 -0000
Message-id: <199906142351.QAA06182@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00162.html
Content-length: 1701

I'd like to propose a semi-formalization of the current testsuite
organization, basically just reflecting current practice, but with
enough precision to guide further additions.  The testsuite is key for
GDB developers; the breadth of functionality and platforms is now so
broad, in many cases, users won't discover regressions for months or
years after the change that caused them; while a testsuite run often
reveals mistakes right away.

First of all, testsuite organization mainly serves the purpose of
intelligibility; DejaGNU finds all the expect scripts wherever they're
placed.  But with around 6000 tests in all, it becomes important to
organize them sensibly.

gdb.base	This is the base testsuite.  The tests in it should
		apply to all configurations of GDB (but generic
		native-only tests may live here).  The test programs
		should be in a subset of C that is valid K&R, ANSI/ISO,
		and C++ (ifdefs are allowed).

gdb.<lang>	Language-specific tests for all languages besides C.

gdb.<platform>	Non-portable tests.  The tests are specific to a specific
		configuration (host or target), such as HP-UX or eCos.

gdb.<compiler>	Tests specific to a particular compiler.  There aren't
		currently any groups of tests in this category that
		couldn't just as sensibly be made platform-specific,
		but one could imagine a gdb.gcc, for tests of GDB's
		handling of GCC extensions.

gdb.<subsystem>	Tests that exercise a specific subsystem in more depth.
		For instance, gdb.disasm exercises various disassemblers,
		while gdb.stabs tests pathways through the stabs reader.

Please feel free to comment on this.  If everybody thinks this is great,
I'll add to the internals manual.

								Stan
From shebs@cygnus.com Mon Jun 14 16:59:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 16:59:00 -0000
Message-id: <199906142359.QAA06291@andros.cygnus.com>
References: <5mwvx62vl7.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q2/msg00163.html
Content-length: 777

   Date: 14 Jun 1999 16:47:32 -0700
   Lines: 39

   Bleh.  But that's what the 'q' escape is for.  IMO, all experimental
   protocol extensions should be using 'q'; likewise, GDB should never
   use 'q' itself.

You mean like with qOffsets, that's been standardly issued by GDB for
years? :-)

Actually, I don't ever remember hearing that 'q' was supposed to be
experimental, and the existing docs don't seem to say so either.  At
this point we would have to pick a different char I think, and be very
disciplined about not allowing any usages of it into the standard
sources, so that it really can be for experimentation.

In general, we have a sizeable documentation gap with the remote
protocol; it's become so ubiquitous it ought to have its own RFC... :-)

								Stan