Re: breakpoint extension for remote protocol, take II

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

>>>>> "Toshiyasu" == Toshiyasu Morita <tm@netcom.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.

Toshiyasu> Is there a four-byte sequence which is an illegal
Toshiyasu> instruction in both MIPS16 and MIPS32 modes?

Even if there were, I don't think it would work.

If you installed this four byte sequence in a 16 bit code segment at
0x1000, it would also overwrite the instruction at 0x1002.  If that
instruction is a branch target, bad things are likely to happen.  A
bit of compiler support to insert a nop before branch targets could
possibly make this work, but that would diminish any benefit high
density instructions are supposed to offer.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Mon Jun 14 18:01:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Testsuite Organization Proposal
Date: Mon, 14 Jun 1999 18:01:00 -0000
Message-id: <3765A5CE.E9C8B0E9@cygnus.com>
References: <199906142351.QAA06182@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00170.html
Content-length: 1173

Stan Shebs wrote:
> 
> 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).

I'd kind of like to see gdb.base contain no C++ tests.  There are
targets out there that don't have a C++ compiler.

	Andrew
From ac131313@cygnus.com Mon Jun 14 18:13:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 18:13:00 -0000
Message-id: <3765A855.5EF176AF@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00171.html
Content-length: 1140

Stan Shebs wrote:
> 
>    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? :-)

And QCrc.  I've just had this one pointed out to me ....

> 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.

I'd like to seriously propose that:

	[qQ][A-Z].*

be reserved for GDB's internal use while:

	[qQ][a-z].*

be declared as available for custom jobs.  In addition, custom packets
include a clearly reconisable identifier vis:

	qcygnus.badhack


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

Comming ...

	Andrew
From ac131313@cygnus.com Mon Jun 14 19:00:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Unused remote protocol letters?
Date: Mon, 14 Jun 1999 19:00:00 -0000
Message-id: <3765B333.6B886FB7@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00172.html
Content-length: 237

Hello,

Using pencil and paper and a glance through several sources I think the
following letters (upper and lower case) havn't been taken yet:

	a, e, f, i, j, l, n, o, u, v, w, y, z

Anyone care to concure with this?

	Andrew
From ac131313@cygnus.com Mon Jun 14 19:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Unused remote protocol letters?
Date: Mon, 14 Jun 1999 19:15:00 -0000
Message-id: <3765B4B6.32B11EA7@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com> <3765B333.6B886FB7@cygnus.com>
X-SW-Source: 1999-q2/msg00173.html
Content-length: 426

Andrew Cagney wrote:
> 
> Hello,
> 
> Using pencil and paper and a glance through several sources I think the
> following letters (upper and lower case) havn't been taken yet:
> 
>         a, e, f, i, j, l, n, o, u, v, w, y, z
> 
> Anyone care to concure with this?

(Following up to ones own e-mail ...)

``A'' is apparently the arguments packet...

Lets try:

	e, f, i, j, l, n, o, u, v, w, y, z

	Andrew
From jsm@cygnus.com Mon Jun 14 22:59:00 1999
From: Jason Molenda <jsm@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Old GDB releases are now available by anon-ftp
Date: Mon, 14 Jun 1999 22:59:00 -0000
Message-id: <19990614225906.A3608@cygnus.com>
X-SW-Source: 1999-q2/msg00174.html
Content-length: 660

I have put a collection of old GDB releases on-line at

	ftp://sourceware.cygnus.com/pub/gdb/releases/ANCIENT/

I have collected GDB releases going back to GDB 2.4, released in January,
1988.  I think I have most of them from about 3.4 and on.  Earlier than
3.4, I'm missing many of the releasees.

These old releases are completely useless on modern hardware, don't
even think about using any of them.  Every so often someone needs to
look into an old version of GDB for some reason or another; this archive
should be helpful for those people.

If you have any old gdb releases sitting around that I do not have in
this collection, please let me know.

Jason
From brendan@dgs.monash.edu.au Tue Jun 15 17:11:00 1999
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: binutils <binutils@sourceware.cygnus.com>, Dan Malek <dmalek@jlc.net>, Magnus Damm <eramdam@kieray1.p.y.ki.era.ericsson.se>, gdb <gdb@sourceware.cygnus.com>
Subject: Using objdump to force a section to load with gdb.
Date: Tue, 15 Jun 1999 17:11:00 -0000
Message-id: <3766EA73.123505A6@dgs.monash.edu.au>
X-SW-Source: 1999-q2/msg00175.html
Content-length: 2181

I have a linux kernel compiled for a mpc860 target and am trying to get
it to run by downloading it into memory using a background debugger
(BDM).  The boot code gets to the point where it trys to uncompress the
kernel but fails because the image isn't loaded into memory (only .text,
.rodata and .data are loaded).  I tried using objcopy to set the "image"
section to "load" but it does not seem to work.  How can I get gdb to
load the image section (either using a gdb command or binutils) ?

Thanks,
Brendan Simon.

Here is a before/after trace using objcopy --set-section-flags.  As you
can see, the load attribute is not set.  I've tried all combinations of
attributes but I can't get it to work.  Am I doing something wrong ?

powerpc-linux-objdump --section-headers myzimage
myzimage:     file format elf32-powerpc
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004324  00100000  00100000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000460  00104330  00104330  00014330  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000002f8  00105000  00105000  00015000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000bbac  00106000  00106000  00016000  2**2
                  ALLOC
  4 image         0006ccbf  00000000  00000000  00016000  2**0
                  CONTENTS, READONLY

powerpc-linux-objcopy --set-section-flags=image=load myzimage

powerpc-linux-objdump --section-headers myzimage
myzimage:     file format elf32-powerpc
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004324  00100000  00100000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000460  00104330  00104330  00014330  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000002f8  00105000  00105000  00015000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000bbac  00106000  00106000  00016000  2**2
                  ALLOC
  4 image         0006ccbf  00000000  00000000  00016000  2**0
                  CONTENTS