* Re: RDI target broken in 000215 snapshot
[not found] ` <38B2AD14.7B0B4A4E@redhat.com>
@ 2000-02-24 10:47 ` Grant Edwards
2000-04-01 0:00 ` Fernando Nasser
2000-04-01 0:00 ` Grant Edwards
1 sibling, 1 reply; 6+ messages in thread
From: Grant Edwards @ 2000-02-24 10:47 UTC (permalink / raw)
To: Fernando Nasser; +Cc: gdb
On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote:
> > The RDI target support seems to be broken in the 000215
> > snapshot.
>
> Can you be more specific? It is working right with the AEB board and
> with another one I have here. Both use serial ports.
(I'm now using 000222)
When I download code with the "load" command, the byte order of
the data gets flipped -- it ends up in little-endian order
(it's big-endian in the file, and I need it to stay that way
when it is downloaded). Downloading with a patched 4.18 doesn't
have this problem.
--
Grant Edwards
grante@visi.com
From fnasser@cygnus.com Thu Feb 24 11:16:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 11:16:00 -0000
Message-id: <38B58292.3B11D622@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com>
X-SW-Source: 2000-02/msg00007.html
Content-length: 1221
Grant Edwards wrote:
>
> On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote:
>
> > > The RDI target support seems to be broken in the 000215
> > > snapshot.
> >
> > Can you be more specific? It is working right with the AEB board and
> > with another one I have here. Both use serial ports.
>
> (I'm now using 000222)
>
> When I download code with the "load" command, the byte order of
> the data gets flipped -- it ends up in little-endian order
> (it's big-endian in the file, and I need it to stay that way
> when it is downloaded). Downloading with a patched 4.18 doesn't
> have this problem.
>
Grant,
A few questions (while I rebuild from the 22 sources):
What compiler, in what host and with which parameters did you generate your executable file?
Is it the same one you can successifuly load with the patched 4.18?
In both cases you are loading the program into the AEB board, right?
I forgot, which host are you running gdb in? Linux, Solaris, Cygwin?
Thanks,
Fernando
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From grante@visi.com Thu Feb 24 11:33:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 11:33:00 -0000
Message-id: <20000224133238.A723@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com>
X-SW-Source: 2000-02/msg00008.html
Content-length: 1495
On Thu, Feb 24, 2000 at 02:12:18PM -0500, Fernando Nasser wrote:
> > When I download code with the "load" command, the byte order of
> > the data gets flipped -- it ends up in little-endian order
> > (it's big-endian in the file, and I need it to stay that way
> > when it is downloaded). Downloading with a patched 4.18 doesn't
> > have this problem.
> >
> Grant,
>
> What compiler, in what host and with which parameters did you
> generate your executable file?
$ uname -a
Linux grante.comtrol.com 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown
$ arm-elf-gcc --version
2.95.2
$ arm-elf-as --version
GNU assembler 991018
$ make
arm-elf-as --gstabs -EB -m arm7tdmi -amhlsnd=memconfigR10_S0_D100.lst -o memconfigR10_S0_D100.o memconfigR10_S0_D100.s
arm-elf-gcc -g -mcpu=arm7tdmi -fverbose-asm -mbig-endian -Wl,-Map,memconfigR10_S0_D100.map -nostartfiles -o memconfigR10_S0_D100 memconfigR10_S0_D100.o -T./memconfig.ld -nostdlib libgcc.a
> Is it the same one you can successifuly load with the patched 4.18?
Yes.
> In both cases you are loading the program into the AEB board, right?
No. I'm loading to custom hardware (big-endian), but I verified
that the same thing happens with the Samsung SNDS eval board
(also big-endian hardware).
I've used the EPI Jeeni (via ethernet) and the ARM Embedded ICE
(via serial port) and had the same results.
> I forgot, which host are you running gdb in? Linux, Solaris, Cygwin?
Linux (same as above).
--
Grant Edwards
grante@visi.com
From grante@visi.com Thu Feb 24 11:46:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 11:46:00 -0000
Message-id: <20000224134607.A6354@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com>
X-SW-Source: 2000-02/msg00009.html
Content-length: 984
Another interesting bit of info. The new snapshot is apparently not
detecting the endianness of the target (both the sessions below were
with a Samsung SNDS evel board (big-endian):
$ arm-elf-gdb
GNU gdb 4.18
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
Rebuilt on Apr 1 1998 at 00:43:57
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently big endian)
$ ~/gdb-000222/gdb/gdb
GNU gdb 000222
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
Rebuilt on Apr 1 1998 at 00:43:57
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently little endian)
--
Grant
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot
[not found] ` <20000224134607.A6354@visi.com>
@ 2000-02-24 12:01 ` Fernando Nasser
[not found] ` <38B59CE1.4CFA7F1E@cygnus.com>
1 sibling, 0 replies; 6+ messages in thread
From: Fernando Nasser @ 2000-02-24 12:01 UTC (permalink / raw)
To: Grant Edwards; +Cc: Fernando Nasser, gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 49606 bytes --]
Grant Edwards wrote:
>
> Another interesting bit of info. The new snapshot is apparently not
> detecting the endianness of the target (both the sessions below were
> with a Samsung SNDS evel board (big-endian):
>
I guess you got it.
Can you set the endianess and do the load after that?
Please let me know if it worked.
In the meanwhile I will check for differences (my build is still going on :-)
Thanks,
Fernando
> $ arm-elf-gdb
> GNU gdb 4.18
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr 1 1998 at 00:43:57
> Serial Rate: 9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently big endian)
>
>
> $ ~/gdb-000222/gdb/gdb
> GNU gdb 000222
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr 1 1998 at 00:43:57
> Serial Rate: 9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently little endian)
>
> --
> Grant
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From grante@visi.com Thu Feb 24 12:16:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 12:16:00 -0000
Message-id: <20000224141648.A1896@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B58DAE.9CAA0A59@cygnus.com>
X-SW-Source: 2000-02/msg00011.html
Content-length: 385
>
> > Another interesting bit of info. The new snapshot is apparently not
> > detecting the endianness of the target (both the sessions below were
> > with a Samsung SNDS evel board (big-endian):
>
>
> I guess you got it.
>
> Can you set the endianess and do the load after that?
Yes. If I set endian to big, then code gets downloaded properly.
--
Grant Edwards
grante@visi.com
From fnasser@cygnus.com Thu Feb 24 13:06:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 13:06:00 -0000
Message-id: <38B59CE1.4CFA7F1E@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com>
X-SW-Source: 2000-02/msg00012.html
Content-length: 2553
> >
> > > Another interesting bit of info. The new snapshot is apparently not
> > > detecting the endianness of the target (both the sessions below were
> > > with a Samsung SNDS evel board (big-endian):
> >
> >
> > I guess you got it.
> >
> > Can you set the endianess and do the load after that?
>
> Yes. If I set endian to big, then code gets downloaded properly.
>
> --
> Grant Edwards
> grante@visi.com
At least you have a way to work now. Just add a .gdbinit with the set endian command on your project directory (the one
you want to be big endian).
We can now, with less pressure, discuss what is going on.
The default for arm targets is "selectable" and "little endian".
This is introduced in december by Stan, who checked in a patch from Scott.
The ChangeLog fails to mention this change!!! But cvs diff never lies... ;-)
I believe the ideal scenario would be to have this thing set in a "smart" way.
The current RDI code just ignores the endianess indication returned by the target.
Maybe we could use that to set the endianess (only if "auto" is selected, please) of the target.
I don't know if this will work, but I can try when I get back.
Of course, you can try that yourself and submit a patch :-)
The interesting line is in remote-rdi.c:279
Cheers,
Fernando
Grant Edwards wrote:
>
> Another interesting bit of info. The new snapshot is apparently not
> detecting the endianness of the target (both the sessions below were
> with a Samsung SNDS evel board (big-endian):
>
> $ arm-elf-gdb
> GNU gdb 4.18
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr 1 1998 at 00:43:57
> Serial Rate: 9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently big endian)
>
>
> $ ~/gdb-000222/gdb/gdb
> GNU gdb 000222
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr 1 1998 at 00:43:57
> Serial Rate: 9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently little endian)
>
> --
> Grant
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From grante@visi.com Thu Feb 24 13:27:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 13:27:00 -0000
Message-id: <20000224152638.A2092@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com>
X-SW-Source: 2000-02/msg00013.html
Content-length: 1248
On Thu, Feb 24, 2000 at 04:04:33PM -0500, Fernando Nasser wrote:
> > > > Another interesting bit of info. The new snapshot is apparently not
> > > > detecting the endianness of the target (both the sessions below were
> > > > with a Samsung SNDS evel board (big-endian):
> > >
> > > I guess you got it.
>
> The default for arm targets is "selectable" and "little endian".
> This is introduced in december by Stan, who checked in a patch from Scott.
> The ChangeLog fails to mention this change!!! But cvs diff never lies... ;-)
Nope.
> I believe the ideal scenario would be to have this thing set in
> a "smart" way. The current RDI code just ignores the endianess
> indication returned by the target. Maybe we could use that to
> set the endianess (only if "auto" is selected, please) of the
> target. I don't know if this will work, but I can try when I
> get back.
I had assumed that gdb was detecting the endianness of the
target already (before today, I didn't know it was user
selectable). I'll take a look at make the "auto" mode pay
attention to the target hardware indication. One could then
generate a warning if the endiannes of the target and the
endianness of a file being loaded disagree.
--
Grant Edwards
grante@visi.com
From fnasser@cygnus.com Thu Feb 24 13:44:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 13:44:00 -0000
Message-id: <38B5A5D1.B2C0EB96@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00014.html
Content-length: 786
Grant Edwards wrote:
>
> I had assumed that gdb was detecting the endianness of the
> target already (before today, I didn't know it was user
> selectable). I'll take a look at make the "auto" mode pay
> attention to the target hardware indication. One could then
> generate a warning if the endiannes of the target and the
> endianness of a file being loaded disagree.
>
Good idea. If the endianess is set to auto, then you set it appropriately.
If not, and it differs from the target, a warning is in order.
You got no indication at all that something was wrong.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From grante@visi.com Thu Feb 24 14:18:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 14:18:00 -0000
Message-id: <20000224161811.A2505@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00015.html
Content-length: 617
On Thu, Feb 24, 2000 at 03:26:38PM -0600, Grant Edwards wrote:
> I had assumed that gdb was detecting the endianness of the
> target already (before today, I didn't know it was user
> selectable). I'll take a look at makeing the "auto" mode pay
> attention to the target hardware indication.
Does the Angel monitor report the current hardware status
correctly? The EPI Jeeni correctly reports my target is
big-endian, but the ARM EmbeddedICE reports that it is little.
Unless most targets correctly report correct endian status,
it's probably not worth paying attention to it.
--
Grant Edwards
grante@visi.com
From bgat@usa.net Thu Feb 24 14:44:00 2000
From: William A.Gatliff <bgat@usa.net>
To: gdb@sourceware.cygnus.com
Subject: gdb configure core dumps
Date: Thu, 24 Feb 2000 14:44:00 -0000
Message-id: <20000224224408.2947.qmail@nwcst283.netaddress.usa.net>
X-SW-Source: 2000-02/msg00016.html
Content-length: 474
Guys:
I'm trying to configure gdb-4.18 on a fresh install of RH6.1, and it isn't
working.
It seems as though no matter what I supply for arguments to configure
(including no arguments at all), I always get back the same thing as if I had
typed --help, and a core file appears in the directory.
Any ideas? I'm stumped...
b.g.
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
From echristo@cygnus.com Thu Feb 24 15:24:00 2000
From: Eric Christopher <echristo@cygnus.com>
To: "William A.Gatliff" <bgat@usa.net>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb configure core dumps
Date: Thu, 24 Feb 2000 15:24:00 -0000
Message-id: <38B5BDDF.6E73AEF4@cygnus.com>
References: <20000224224408.2947.qmail@nwcst283.netaddress.usa.net>
X-SW-Source: 2000-02/msg00017.html
Content-length: 286
> It seems as though no matter what I supply for arguments to configure
> (including no arguments at all), I always get back the same thing as if I had
> typed --help, and a core file appears in the directory.
>
What does 'file core' say? Perhaps there is some issue with sh?
-eric
From hanymorcos@yahoo.com Thu Feb 24 15:27:00 2000
From: Hany Morcos <hanymorcos@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: Debugging a constructor
Date: Thu, 24 Feb 2000 15:27:00 -0000
Message-id: <20000224232705.13750.qmail@web3207.mail.yahoo.com>
X-SW-Source: 2000-02/msg00018.html
Content-length: 431
How do I print the variable values inside
a constructor?
I can't use this... Because doesn't exist yet..
The object hasn't been constructed...
Then how do I print the value of x??
class y{
public:
y(int* x) {x =
coreDumpAndGenerateManyHeadaches(); // print x inside
gdb } ;
};
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From hanymorcos@yahoo.com Thu Feb 24 16:31:00 2000
From: Hany Morcos <hanymorcos@yahoo.com>
To: Hany Morcos <hanymorcos@yahoo.com>, gdb@sourceware.cygnus.com
Subject: Re: Debugging a constructor
Date: Thu, 24 Feb 2000 16:31:00 -0000
Message-id: <20000225003041.21219.qmail@web3204.mail.yahoo.com>
X-SW-Source: 2000-02/msg00019.html
Content-length: 686
Got it
thank you
--- Hany Morcos <hanymorcos@yahoo.com> wrote:
>
>
> How do I print the variable values inside
> a constructor?
>
> I can't use this... Because doesn't exist yet..
> The object hasn't been constructed...
>
> Then how do I print the value of x??
>
> class y{
>
> public:
> y(int* x) {x =
> coreDumpAndGenerateManyHeadaches(); // print x
> inside
> gdb } ;
> };
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From ac131313@cygnus.com Thu Feb 24 18:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 18:55:00 -0000
Message-id: <38B5EEDB.8A8F2DD8@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00020.html
Content-length: 2275
FYI,
The current behavior is determined by gdbarch.c:
o it starts in auto mode using
TARGET_BYTE_ORDER_DEFAULT as an
initial value or (chosen arbitrarily)
BIG_ENDIAN as the next best guess.
o as soon as GDB encounters a binary
it pokes around the bfd file to determine
the endianess and uses that (provided things
are still auto).
To the best of my knowledge, no one has seriously investigated how to
set up an interface where the target determines architectural
information (such as endianess).
As for the current problem:
$ arm-elf-gdb
GNU gdb 4.18
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT
2.11a)
Rebuilt on Apr 1 1998 at 00:43:57
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently big endian)
$ ~/gdb-000222/gdb/gdb
GNU gdb 000222
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT
2.11a)
Rebuilt on Apr 1 1998 at 00:43:57
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently little endian)
it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
wrong place.
enjoy,
Andrew
Fernando Nasser wrote:
>
> Grant Edwards wrote:
> >
> > I had assumed that gdb was detecting the endianness of the
> > target already (before today, I didn't know it was user
> > selectable). I'll take a look at make the "auto" mode pay
> > attention to the target hardware indication. One could then
> > generate a warning if the endiannes of the target and the
> > endianness of a file being loaded disagree.
> >
> Good idea. If the endianess is set to auto, then you set it appropriately.
> If not, and it differs from the target, a warning is in order.
> You got no indication at all that something was wrong.
>
> --
> Fernando Nasser
> Red Hat - Toronto E-Mail: fnasser@cygnus.com
> 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
> Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Thu Feb 24 19:35:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: kevinb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 19:35:00 -0000
Message-id: <38B5F82F.D4C46B90@cygnus.com>
References: <1000222025201.ZM9805@ocotillo.lan> <200002221013.e1MAD3A00261@delius.kettenis.local> <1000224102541.ZM14031@ocotillo.lan> <200002241047.LAA02405@landau.wins.uva.nl>
X-SW-Source: 2000-02/msg00021.html
Content-length: 1318
Mark Kettenis wrote:
>
> Date: Thu, 24 Feb 2000 03:25:41 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
>
> On Feb 22, 11:13am, Mark Kettenis wrote:
>
> [Detailed failure analysis snipped]
>
> > Anyway, I hope this helps,
>
> It did indeed. Thanks! (It showed me where not to focus my attention
> first.)
>
> I'll respond to the sourceware list when I've had more time to study
> your analysis, but in the meantime, I wanted to send you a note to let
> you know that I appreciated your analysis...
>
> Meanwhile, I learned something more about the
>
> gdb.base/annota1.exp: backtrace @ signal handler
>
> failure I reported. There is nothing wrong with the test per se.
> It's just that on my i586-pc-linux-gnu system the regexp matching
> takes an awful lot of time. Setting the timeout to 10 minutes made
> the test pass. This is probably related to the fact that with glibc
> there is an extra frame. Apparently the fix I suggested (but didn't
> understand), speeded up the regexp matching somewhat, but even in that
> case (with the default timeout) the test failed on my system last
> night.
Have a look at gdb.base/call-ar-st.exp and how it used
``gdb_expect_list''. Patches that make the testsuite run 10 minutes
faster are always more than welcome :-)
Andrew
From grante@visi.com Thu Feb 24 19:57:00 2000
From: Grant Edwards <grante@visi.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 19:57:00 -0000
Message-id: <20000224215652.A7650@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B5EEDB.8A8F2DD8@cygnus.com>
X-SW-Source: 2000-02/msg00022.html
Content-length: 801
> o as soon as GDB encounters a binary
> it pokes around the bfd file to determine
> the endianess and uses that (provided things
> are still auto).
That implies that when I loaded a big-endian file it should have
switched to big-endian. It didn't seem to -- I'll have to try that
again.
> To the best of my knowledge, no one has seriously investigated how to
> set up an interface where the target determines architectural
> information (such as endianess).
Since 50% of my sample of 2 target interfaces don't correctly report
endianess, it may not be something worth investigating.
> it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
> wrong place.
Now that I know what happened, it's not a big deal. I can just set it
in .gdbinit.
--
Grant Edwards
grante@visi.com
From ac131313@cygnus.com Thu Feb 24 22:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 22:11:00 -0000
Message-id: <38B61CF6.B4F80802@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00023.html
Content-length: 1084
Grant Edwards wrote:
>
> > o as soon as GDB encounters a binary
> > it pokes around the bfd file to determine
> > the endianess and uses that (provided things
> > are still auto).
>
> That implies that when I loaded a big-endian file it should have
> switched to big-endian. It didn't seem to -- I'll have to try that
> again.
Possibly not. If you were using:
(gdb) load file-with-random-format
then GDB won't look at the file. I should have said that something like
gdb sets the endianess once the debug file is specified (via ``file'' or
a few other commands) vis:
(gdb) file debug-file
(gdb) load
``load'' tends to not have side effects (and when it does, they are
hotly debated :-)
> > it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
> > wrong place.
>
> Now that I know what happened, it's not a big deal. I can just set it
> in .gdbinit.
It's more a question of should the endianess have changed between
releases or should it have been little-endian anyway. Not my problem
:-)
Andrew
From fnasser@redhat.com Fri Feb 25 07:08:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Fri, 25 Feb 2000 07:08:00 -0000
Message-id: <38B69A2A.ED2DC6F3@redhat.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com>
X-SW-Source: 2000-02/msg00024.html
Content-length: 962
Andrew Cagney wrote:
>
> It's more a question of should the endianess have changed between
> releases or should it have been little-endian anyway. Not my problem
> :-)
>
I inherited this one :-)
But you are right, this will at least require an entry in the NEWS, as
it alters some previous behavior. *If* the arm users in the list decide
that the default should be little-endian. It does seem reasonable and
if the file command straights it out, only the load users would have to
care (but they are more aware of these issues, and can always have the
set endian on their .gdbinit).
It is a shame that Angel is so buggy. The return code should
appropriately indicate the endianess of the target -- it would be a
nice feature to use :-(
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From grante@visi.com Fri Feb 25 07:14:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Fri, 25 Feb 2000 07:14:00 -0000
Message-id: <20000225091418.B3106@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com>
X-SW-Source: 2000-02/msg00025.html
Content-length: 1379
On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote:
> > It's more a question of should the endianess have changed between
> > releases or should it have been little-endian anyway. Not my problem
> > :-)
>
> I inherited this one :-)
>
> But you are right, this will at least require an entry in the
> NEWS, as it alters some previous behavior. *If* the arm users
> in the list decide that the default should be little-endian.
From what I've seen/read little-endian is more common (does
ARM-Linux run little-endian or big?), and it's the default for
gcc/binutils, so it should probably be the default for gdb as
well. I was just confused because I thought "auto" meant that it
would be determined by the target.
> It does seem reasonable and if the file command straights it
> out, only the load users would have to care (but they are more
> aware of these issues, and can always have the set endian on
> their .gdbinit).
Having the load command warn the user if the target and file
differ might also be something to consider.
> It is a shame that Angel is so buggy. The return code should
> appropriately indicate the endianess of the target -- it would
> be a nice feature to use :-(
Does Angel not report it correctly? The ARM EmbeddedICE is
broken in that respect, but I don't have a copy of Angel
running anywhere.
--
Grant Edwards
grante@visi.com
From fnasser@redhat.com Fri Feb 25 07:29:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Grant Edwards <grante@visi.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Fri, 25 Feb 2000 07:29:00 -0000
Message-id: <38B69F56.5ECE30F6@redhat.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com> <20000225091418.B3106@visi.com>
X-SW-Source: 2000-02/msg00026.html
Content-length: 1689
Grant Edwards wrote:
>
> Having the load command warn the user if the target and file
> differ might also be something to consider.
>
The trick is how to know the target endianess. Also, note that the file
being loaded by the load command ay not have this info. The file
command is the one that reads files from where this can be determined.
> Does Angel not report it correctly? The ARM EmbeddedICE is
> broken in that respect, but I don't have a copy of Angel
> running anywhere.
>
My mistake. I thought you made reference to an Angel board on you 50/50
little statistic.
I have two little-endian boards running two different versions of
Angel. I will check wen I get back.
But I guess you are right, we should assume that the target RDI protocol
is working properly and check for the endianess. For the boards/devices
that are broken, the user will have to turn off the auto mode and set
the endianess appropriately on his/her .gdbinit. Another possibility is
that we just issue a warning (instead of setting the endianess) based on
the result returned from the board. If it is a board/device with a know
problem of returning the wrong info, the user will just ignore the
warning. To make GUI users happier, he warning would not be issued if
auto is turned off (what means that the user set deliberately the
endianess so he/she should know what he/she is doing).
BTW: AFAIK Linux-arm is little endian, and that is why Stan and Scott
changed the default.
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From scottb@netwinder.org Fri Feb 25 10:11:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: "fnasser@cygnus.com" <fnasser@cygnus.com>
Cc: James Ingham <jingham@cygnus.com>, GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: bug in arm_push_arguments()
Date: Fri, 25 Feb 2000 10:11:00 -0000
Message-id: <38B6C4A1.7A1461C4@netwinder.org>
X-SW-Source: 2000-02/msg00027.html
Content-length: 4031
Hi guys,
I've been looking at this function as there are regressions in
gdb.base/callfuncs. In particular I've been looking at this code.
/* ANSI C code passes float arguments as integers, K&R code
passes float arguments as doubles. The .stabs record for
for ANSI prototype floating point arguments records the
type as FP_INTEGER, while a K&R style (no prototype)
.stabs records the type as FP_FLOAT. In this latter case
the compiler converts the float arguments to double before
calling the function. */
if (TYPE_CODE_FLT == typecode && REGISTER_SIZE == len)
{
float f;
double d;
char * bufo = (char *) &d;
char * bufd = (char *) &dbl_arg;
len = sizeof (double);
f = *(float *) val;
SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */
d = f;
/* We must revert the longwords so they get loaded into the
the right registers. */
memcpy (bufd, bufo + len / 2, len / 2);
SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */
memcpy (bufd + len / 2, bufo, len / 2);
SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
val = (char *) &dbl_arg;
}
I added this particular piece of code to handle functions without prototypes
that pass floats as parameters, because the compiler treats them differently.
Someone added code which is attempting the following (see my comments):
/* The value is in TARGET byte order. Convert it to HOST byte
order in preparation for conversion to a double. */
f = *(float *) val;
SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */
/* Convert the float to a double in HOST byte order. */
d = f;
/* Convert the double to TARGET byte order and swap things to
conform to the ARM floating point layout. */
memcpy (bufd, bufo + len / 2, len / 2);
SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */
memcpy (bufd + len / 2, bufo, len / 2);
SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
val = (char *) &dbl_arg;
This is ok, but the code for the last step is unnecessarily complex. I think
something similar to the following should suffice.
int tmp, *buf = &d;
SWAP_TARGET_AND_HOST (&d, sizeof (double));
tmp = buf[0];
buf[0] = buf[1];
buf[1] = tmp;
I think this will result in better code from the compiler. There are a couple
of problems though with this code. First what happens if sizeof (TARGET_DOUBLE)
!= sizeof (HOST_DOUBLE). Second, this breaks in the native case, because the
double is already in the right format. This is why I have regressions I believe
(I have yet to test my theory). Is there a clean way to solve these problems?
I also noticed this comment while investigating. I disabled the code when I
rewrote the function. I didn't know what it was for, and I wasn't sure it
should stay. I left it for Stan and Jim to evaluate. If it is necessary I
would document what it does and why it does it, and get rid of question. In
particular why is setting the mode bit fine?
#if 1
/* I don't know why this code was disable. The only logical use
for a function pointer is to call that function, so setting
the mode bit is perfectly fine. FN */
/* If the argument is a pointer to a function, and it is a Thumb
function, set the low bit of the pointer. */
if (TYPE_CODE_PTR == typecode
&& NULL != target_type
&& TYPE_CODE_FUNC == TYPE_CODE (target_type))
{
CORE_ADDR regval = extract_address (val, len);
if (arm_pc_is_thumb (regval))
store_address (val, len, MAKE_THUMB_ADDR (regval));
}
#endif
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From jimb@cygnus.com Fri Feb 25 10:27:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: patch database proposal
Date: Fri, 25 Feb 2000 10:27:00 -0000
Message-id: <200002251827.NAA09955@zwingli.cygnus.com>
X-SW-Source: 2000-02/msg00028.html
Content-length: 8847
Here's a tentative proposal for how the patch database should work.
In reality, a good part of this is set up and ready to go, but there's
nothing we can't revise, in the presence of good ideas or persuasive
criticism.
Please let me know what you think; post your comments to the list.
----
If you've written a patch for GDB, either to fix a bug or to improve
the program, you should make sure it gets into the GDB patch database.
The GDB patch database is a GNATS database created to help GDB's
maintainers keep track of patches that need reviewing, and helps you
stay on top of what's happening to your patch.
Anyone can submit a patch. There are two ways to do so:
- Visit the GDB Patch Submission page [Jason will supply URL], and
submit your patch there.
- Submit your patches via E-mail, by sending a message to
`gdb-patches-gnats@sourceware.cygnus.com'. We have a template for
mail messages [link here]. Following this template helps make sure
we have the information we need to choose a reviewer for your patch,
and to do the review itself.
We'd prefer that you use the web form, if possible, because that
provides more helpful prompts, and checks your input more thoroughly.
The database assigns each new patch a number, like `gdb-patch/209'.
Whenever you send mail regarding your patch, be sure to include the
address `gdb-patches-gnats@sourceware.cygnus.com' in the CC list, and
make sure the message subject starts with `gdb-patch/209: ', or
whatever your patch number is. This way, GNATS will automatically log
the discussion along with the patch in the database.
Once you've submitted your patch, you can visit [another URL] to check
on its status, or to search the patch database in various ways. Each
patch in the database has a set of headers, much like a mail message;
the two most interesting headers to look at are:
- `Responsible' --- this is the name of the person currently
responsible for moving the patch forward.
- `State' --- the current status of the patch.
Here are the different states a patch might be in:
- `unclaimed'
If the database software can't figure out automatically which
maintainer should evaluate your patch, then it declares the patch
`unclaimed', and sets the `Responsible' person to the GDB patch
secretary. It is then the secretary's job to find someone who can
review the patch, and change the patch's `State' and `Responsible'
headers appropriately.
Also, if the maintainer responsible for a patch decides that they
can't process it --- for example, they might know they won't be able
to evaluate it promptly --- then they can put it back in the
`unclaimed' state. As before, the patch secretary should find
someone else to tend to it. The patch database logs all changes
to a patch's state or responsible party, along with all mail
communication about the patch, which can help the new person pick
the patch where it left off.
- `claimed'
The person named in the patch's `Responsible' header has volunteered
or been designated to review the patch, but they haven't made any
decision about it yet, or they haven't gotten around to looking at
it yet.
The maintainer indicates his or her decision by putting the patch in
one of the states below.
If the patch requires additional maintainers' approval, then the
maintainer should leave the patch in the `claimed' state, and simply
change the `Responsible' field to the next maintainer in line.
Since all changes in responsibility are logged with the patch, each
maintainer can tell when the review process is complete. The last
maintainer to evaluate the patch should actually change the state to
something more conclusive.
As the name suggests, patch claims are voluntary. Maintainers
should feel free to claim interesting unclaimed patches for
themselves, and to trade or reallocate patches amongst themselves as
appropriate, simply by changing patches' `State' and `Responsible'
headers. Assignments made automatically by the database software,
or manually by the patch secretary, are simply an optimization,
meant to help the process run more smoothly.
Of course, if a maintainer consistently fails to review patches in a
timely fashion, the team will eventually suggest that they step
down, or share the responsibility with someone more responsive.
- `feedback'
This state indicates that the maintainer feels the patch needs
revision, or that the author's intent is unclear and the patch
should be further explained. It is now the responsibility of the
original author of the patch to satisfy the maintainer's concerns,
to allow the patch to move forward.
The maintainer's concerns should always be recorded with the patch
somehow, either in a mail message logged with the patch, or in the
state change message.
Note that the maintainer is still responsible for patches in this
state. If the author is slow to respond, the maintainer must pursue
the matter, or put the patch in the `rejected' state (described
below) if the author doesn't reply.
- `prereqs'
The maintainer approves of the patch, but can't apply it until some
other change is made --- some other patch must be applied first, for
example. The maintainer should explain what they are waiting for in
the patch record. It is the maintainer's responsibility to notice
when the prerequisites have been met, and move the patch along.
- `accepted'
The maintainer has decided to apply the patch, and has accepted
responsibility for whatever further work is necessary to get it into
the sources.
- `applied'
The maintainer has applied the patch, and expects no further work on
that patch to be necessary.
- `rejected'
This state represents several possible outcomes:
- The maintainer has decided that the patch should not be applied, and
is not expecting to do revisions or further work on that patch.
- The patch's author has withdrawn it, and the maintainer agrees.
- The patch is actually several smaller changes lumped together;
the author must resubmit it as several separate patches.
- The patch is so old that it is no longer useful in revising the
current sources, and neither the author nor the maintainer has any
intention of bringing it up to date.
In any case, the maintainer should explain why the patch was
rejected, in the patch notes.
Of course, it is always possible for a maintainer to resurrect a
rejected patch, simply by putting it back in one of the other
states.
- `papers'
The maintainer would like to apply the patch, but the patch is large
enough that it is automatically copyrighted by the author, and
cannot be applied to the GDB sources. In this case, the author
needs to assign his or her copyright interest in the patch to the
Free Software Foundation; see [link], or the file `gdb/CONTRIBUTE'
in the GDB source tree, for details about this.
[We'll work in full documentation for the other headers somewhere, but
this page is mostly about the process, which is the least obvious
part.]
If you're interested in monitoring patch activity, you may wish to
subscribe to `gdb-patches-prs@sourceware.cygnus.com'. This mailing
list receives:
- messages announcing newly submitted patches
- all discussion about existing patches
- messages indicating that a patch has changed state, and why
To subscribe, [appropriate instructions or link]
If you are having problems using the patch database, send mail to
`gdb-patches-secretary@sourceware.cygnus.com'. The patch secretary
is responsible for:
- the quality of the database (removing spam, getting people to use
the headers in a helpful way, making sure all patches are placed
in the database [in my experience, every database gets dirty, and
there needs to be someone working to counteract entropy]);
- passing `unclaimed' patches to willing and appropriate maintainers;
- all GDB-specific documentation and web pages supporting the patch
database; and
- any other administration specific to the GDB patch database
The patch secretary is not responsible for:
- technical issues (like evaluating patches);
- administration of shared sourceware infrastructure, not specific to the
GDB database (fixing wedged servers, upgrading software, etc.); or
- prodding unresponsive maintainers. (General community pressure is
best for this; beyond that, the prodding needs to be done by
someone with real authority over their time, like their manager,
or authority over their maintainership, like the committee that
made them a maintainer in the first place.)
In the GDB source tree, the file gdb/MAINTAINERS lists the current
patch secretary, along with all the maintainers and the areas they're
responsible for.
From kevinb@cygnus.com Fri Feb 25 11:08:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Re: bug in arm_push_arguments()
Date: Fri, 25 Feb 2000 11:08:00 -0000
Message-id: <1000225190817.ZM16382@ocotillo.lan>
References: <38B6C4A1.7A1461C4@netwinder.org> <scottb@netwinder.org>
X-SW-Source: 2000-02/msg00029.html
Content-length: 3099
On Feb 25, 1:06pm, Scott Bambrough wrote:
> /* ANSI C code passes float arguments as integers, K&R code
> passes float arguments as doubles. The .stabs record for
> for ANSI prototype floating point arguments records the
> type as FP_INTEGER, while a K&R style (no prototype)
> .stabs records the type as FP_FLOAT. In this latter case
> the compiler converts the float arguments to double before
> calling the function. */
> if (TYPE_CODE_FLT == typecode && REGISTER_SIZE == len)
> {
> float f;
> double d;
> char * bufo = (char *) &d;
> char * bufd = (char *) &dbl_arg;
>
> len = sizeof (double);
> f = *(float *) val;
> SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */
> d = f;
> /* We must revert the longwords so they get loaded into the
> the right registers. */
> memcpy (bufd, bufo + len / 2, len / 2);
> SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */
> memcpy (bufd + len / 2, bufo, len / 2);
> SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
> val = (char *) &dbl_arg;
> }
>
> I added this particular piece of code to handle functions without prototypes
> that pass floats as parameters, because the compiler treats them differently.
> Someone added code which is attempting the following (see my comments):
>
> /* The value is in TARGET byte order. Convert it to HOST byte
> order in preparation for conversion to a double. */
> f = *(float *) val;
> SWAP_TARGET_AND_HOST (&f, sizeof (float)); /* adjust endianess */
>
> /* Convert the float to a double in HOST byte order. */
> d = f;
>
> /* Convert the double to TARGET byte order and swap things to
> conform to the ARM floating point layout. */
> memcpy (bufd, bufo + len / 2, len / 2);
> SWAP_TARGET_AND_HOST (bufd, len / 2); /* adjust endianess */
> memcpy (bufd + len / 2, bufo, len / 2);
> SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
> val = (char *) &dbl_arg;
>
> This is ok, but the code for the last step is unnecessarily complex. I think
> something similar to the following should suffice.
>
> int tmp, *buf = &d;
> SWAP_TARGET_AND_HOST (&d, sizeof (double));
> tmp = buf[0];
> buf[0] = buf[1];
> buf[1] = tmp;
>
> I think this will result in better code from the compiler. There are a couple
> of problems though with this code. First what happens if sizeof (TARGET_DOUBLE)
> != sizeof (HOST_DOUBLE). Second, this breaks in the native case, because the
> double is already in the right format. This is why I have regressions I believe
> (I have yet to test my theory). Is there a clean way to solve these problems?
It seems to me that you should be able to use store_floating() to do
what you want. It'll handle both the conversion and the byte swapping.
Kevin
From jtc@redback.com Fri Feb 25 17:04:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: command error handling
Date: Fri, 25 Feb 2000 17:04:00 -0000
Message-id: <5mr9e093zj.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-02/msg00030.html
Content-length: 1257
The CLI for the memory region attributes feature I'm working on is
based on displays. Each memory region created is assigned a number,
and can be enabled, disabled, and deleted.
While stealing the display CLI code, I noticed that when you enable or
disable a non-extant display, a message will be output with printf_-
unfiltered(), but when you do the same thing with delete, GDB calls
error(). The same thing occurs when you attempt to enable/disable/
delete displays with a non-numeric argument. I'll argue that delete
should behave like enable and disable, that a message be output and
execution should continue.
The problem with error(), IMHO, is that it's very heavy handed. While
it allows us to avoid the fun of propagating errors up from the lowest
levels of GDB, it also makes it impossible for user defined functions
to detect the failure of a command (that, plus the fact that there are
no command return values, but that's easily remedied by comparision).
Without such a mechanism, the usefulness of scripting is greatly
diminished. I would expect it to much be the same for all extension
languages that may be bound into GDB.
Is this a (long-term) direction we should be investigating?
--jtc
--
J.T. Conklin
RedBack Networks
From kingdon@redhat.com Sat Feb 26 10:30:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: command error handling
Date: Sat, 26 Feb 2000 10:30:00 -0000
Message-id: <b7lfr6cpc.fsf@rtl.cygnus.com>
References: <5mr9e093zj.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-02/msg00031.html
Content-length: 1005
> I'll argue that delete should behave like enable and disable, that a
> message be output and execution should continue.
Sounds good to me.
> The problem with error(), IMHO, is that it's very heavy handed. While
> it allows us to avoid the fun of propagating errors up from the lowest
> levels of GDB, it also makes it impossible for user defined functions
> to detect the failure of a command
Well, sometimes the command will fail in its entirety. Or to put it
another way, some errors you can't continue from, for example, in
"delete display foo 4 3 5 2" we might be willing to guess that 4, 3,
5, and 2 are display numbers but in a different case the syntax of the
first part has to be right for the last part to make any sense. One
can presumably find non-syntactic examples too.
I haven't taken a close look at the error() machinery recently and how
it would relate to scripting languages, but there should be some way
to trap the error() and return it back to the script.
From weech@primenet.com Sat Feb 26 21:33:00 2000
From: Brent Weech <weech@primenet.com>
To: gdb@sourceware.cygnus.com, cygwin@sourceware.cygnus.com
Subject: GDB error 87 under Cygwin
Date: Sat, 26 Feb 2000 21:33:00 -0000
Message-id: <4.3.2.20000226214059.00b8f008@pop.primenet.com>
X-SW-Source: 2000-02/msg00032.html
Content-length: 1728
Where in the world in the Errors.h file that enumerates the error codes
coming from GDB? In particular, I am interested in error 87, as
shown below:
BLACKBOX> gdb
h-hcube                                                  Â
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i586-cygwin32"...(no debugging
symbols found)...
(gdb) r
Starting program: //e/h-hcube.exe
Error creating process //e/h-hcube.exe, (error 87)
I'm sure the answer to this question is somewhere on the Cygnus and/or
GDB mailing archive, but for the life of me I can't figure out how to get
the wonderfully worthless ht://Dig search engine to accept phrase or
boolean searches with any accuracy. It has got to be one of the
most frustrating search engine software packages I have ever used.Â
For example, try the following:
On the Cygwin Project archive, a search for "error 87" set
to match all terms or a boolean search for "error and 87" both
give 5474 matches.
On the same archive, a search for "error" gives (yes, I'm
sure you can guess) the same 5474 matches!
But on the same archive, a search for "error 193" set to
match all terms only gives 21 hits.
What gives? A search though many of the "error 87"
hits confirms that the string 87 is nowhere in the text or source of the
html page.
Someone tell me how to do a reliable phrase search of the mail
archives.
Brent Weech
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot
[not found] ` <38B5EEDB.8A8F2DD8@cygnus.com>
@ 2000-04-01 0:00 ` Grant Edwards
0 siblings, 0 replies; 6+ messages in thread
From: Grant Edwards @ 2000-04-01 0:00 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Fernando Nasser, Fernando Nasser, gdb
> o as soon as GDB encounters a binary
> it pokes around the bfd file to determine
> the endianess and uses that (provided things
> are still auto).
That implies that when I loaded a big-endian file it should have
switched to big-endian. It didn't seem to -- I'll have to try that
again.
> To the best of my knowledge, no one has seriously investigated how to
> set up an interface where the target determines architectural
> information (such as endianess).
Since 50% of my sample of 2 target interfaces don't correctly report
endianess, it may not be something worth investigating.
> it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
> wrong place.
Now that I know what happened, it's not a big deal. I can just set it
in .gdbinit.
--
Grant Edwards
grante@visi.com
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: "Frank Ch. Eigler" <fche@cygnus.com>
Cc: gdb@sourceware.cygnus.com, Stephane.Bihan@arccores.com
Subject: Re: how to integrate an ISS target in the gdb tree
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D6C365.F2942D51@apple.com>
References: <OF44E75EE3.DD68FAE0-ON802568A8.0056F26A@risccores.com> <o5d7opqr6x.fsf@toenail.to.cygnus.com>
X-SW-Source: 2000-q1/msg00748.html
Content-length: 458
"Frank Ch. Eigler" wrote:
> I believe we will need an FSF copyright assignment, so you may want to get
> started on that paperwork in parallel.
Historically, not all simulators have been assigned to the FSF. But while one
could make an argument that the sims are separate somehow, it doesn't set a very
good precedent - the whole point of the assignment policy is to have consistent
ownership, rather than the patchwork that's currently under sim/.
Stan
From alexey@vocord.com Sat Apr 01 00:00:00 2000
From: Alexey <alexey@vocord.com>
To: gdb@sourceware.cygnus.com
Subject: Need help with remote debug!
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BAA89B.93B653B4@vocord.com>
X-SW-Source: 2000-q1/msg00438.html
Content-length: 315
Hello!
I want to use gdb to remote debug applications on my board with mips
p4650
through the shared memory. I put printk in ioctl in driver. So I can
see what gde send
somthing with cmd 0x5401 and 0x5402 - TCGETS and TCSETS
So the question is: what does gdb send and what he is want to recieve?
Regards
Alexey
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot
[not found] ` <38B69A2A.ED2DC6F3@redhat.com>
@ 2000-04-01 0:00 ` Grant Edwards
0 siblings, 0 replies; 6+ messages in thread
From: Grant Edwards @ 2000-04-01 0:00 UTC (permalink / raw)
To: Fernando Nasser; +Cc: Andrew Cagney, Fernando Nasser, gdb
On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote:
> > It's more a question of should the endianess have changed between
> > releases or should it have been little-endian anyway. Not my problem
> > :-)
>
> I inherited this one :-)
>
> But you are right, this will at least require an entry in the
> NEWS, as it alters some previous behavior. *If* the arm users
> in the list decide that the default should be little-endian.
From what I've seen/read little-endian is more common (does
ARM-Linux run little-endian or big?), and it's the default for
gcc/binutils, so it should probably be the default for gdb as
well. I was just confused because I thought "auto" meant that it
would be determined by the target.
> It does seem reasonable and if the file command straights it
> out, only the load users would have to care (but they are more
> aware of these issues, and can always have the set endian on
> their .gdbinit).
Having the load command warn the user if the target and file
differ might also be something to consider.
> It is a shame that Angel is so buggy. The return code should
> appropriately indicate the endianess of the target -- it would
> be a nice feature to use :-(
Does Angel not report it correctly? The ARM EmbeddedICE is
broken in that respect, but I don't have a copy of Angel
running anywhere.
--
Grant Edwards
grante@visi.com
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: gdb@sourceware.cygnus.com
Subject: C++ Overload testsuite fixes, need someone to verify
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <hfdx6o2m.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00786.html
Content-length: 413
Can someone verify, that i am correct in thinking you get unexpected
failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures?
I have a patch, i just want to make sure it's not me.
It appears the source line the test suite expects main to appear on
in that file is 49, and main really appears at 48, so the regex to
match doesn't work. I diffed the ovldbreak.cc file, and i get no
differences.
--Dan
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: annotate.texi
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003070832.DAA14451@indy.delorie.com>
X-SW-Source: 2000-q1/msg00557.html
Content-length: 433
Is there any reason why annotate.texi shouldn't be @include'd by
gdb.texinfo and be part of the manual? Right now, "set annotate" is
not documented at all, and annotate.texi seems to be just what the
doctor ordered...
And while at that, NEWS seems to be in the need of some work, it
doesn't mention many of the new features that already are in the CVS
tree. I would like at least to mention the improvements in the DJGPP
version.
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000224095244.ZM13976@ocotillo.lan>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <Franz.Sirl-kernel@lauterbach.com>
X-SW-Source: 2000-q1/msg00395.html
Content-length: 890
On Feb 22, 11:09pm, Franz Sirl wrote:
> >I invite those of you who have Linux/PPC machines to try out these
> >changes and let me know how they work. Also, please let me know about
> >any problems that you find.
>
> I've just uploaded an RPM with the current CVS source to
> ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it.
Thanks.
[...]
> A quick test of gdb looked very promising, I already installed it as the
> default gdb on our build system. What about "info float"? Are you going to
> tackle this yourself later or do you want to leave the implementation to
> somebody else?
If someone else is willing to do the implementation for "info float",
I'm willing to integrate the patches. (I rarely have need for "info
float", so it may be better if someone else did the implementation.)
OTOH, if no one sends me patches, I'll try to get to it eventually.
Kevin
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: "J.T. Conklin" <jtc@redback.com>
Cc: Stan Shebs <shebs@apple.com>, gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307162127.D485@lucon.org>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00576.html
Content-length: 534
On Tue, Mar 07, 2000 at 04:18:23PM -0800, J.T. Conklin wrote:
> >>>>> "hjl" == H J Lu <hjl@valinux.com> writes:
>
> hjl> 2000-03-07 H.J. Lu <hjl@gnu.org>
> hjl>
> hjl> * gdb-regex.h: New. Include <regex.h> for glibc 2 and include
> hjl> "gnu-regex.h" otherwise.
>
> If we follow the naming convention we have been using, gdb-regex.h
There are gdb-events.c gdb-events.h gdb-events.sh gdb-regex.h
gdb-stabs.h.
> should be gdb_regex.h.
Either way is fine with me. All I want is regex in glibc 2 :-). Any
objections?
H.J.
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: GDB configure problem in the new repository...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A41C50.F4E522DD@netwinder.org>
X-SW-Source: 2000-q1/msg00222.html
Content-length: 1141
Hi,
I checked out a GDB tree on a clean system from the new repository using:
cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb
and attempted to configure using the following directory structure:
cvstree/src
cvstree/gdb-build
cd gdb-build
../src/configure --prefix=/usr
I get the following error:
checking for Tcl configuration... found /usr/lib/tclConfig.sh
checking for Tk configuration... found /usr/lib/tkConfig.sh
checking for Tcl private headers. dir=unix... checking for tclInt.h... no
configure: error: Can't find Tcl private headers
I checked out the entire tree under src on another machine the other day using
the same setup and I could configure and build with the following results for a
native armv4l-unknown-linux-gnu target on a NetWinder.
=== gdb Summary ===
# of expected passes 6296
# of unexpected failures 56
# of unexpected successes 1
# of expected failures 195
# of unresolved testcases 2
# of untested testcases 5
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: Does today's gdb compile on Linux?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000118104731.B7970@valinux.com>
References: <20000118100532.A7871@valinux.com> <hjl@valinux.com> <1000118184306.ZM1103@ocotillo.lan>
X-SW-Source: 2000-q1/msg00041.html
Content-length: 1621
On Tue, Jan 18, 2000 at 11:43:06AM -0700, Kevin Buettner wrote:
> On Jan 18, 10:05am, H . J . Lu wrote:
>
> > I cannot get today's gdb in CVS to compile on Linux/ia32. It failed on
> > i386-linux-nat.c:
> >
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c: In function `supply_fpregset':
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:215: request for member `st_space' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:217: request for member `cwd' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:218: request for member `swd' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:219: request for member `twd' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:220: request for member `fip' in
> >
> > Any ideas?
>
> It looks to me like HAVE_PTRACE_GETXFPREGS is getting defined in config.h
> when it shouldn't be.
I don't think so.
# grep HAVE_PTRACE_GETXFPREGS config.h
/* #undef HAVE_PTRACE_GETXFPREGS */
>
> The following comment may shed some light...
>
> /* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own
> Linux kernel patch for SSE support. That patch may or may not
> actually make it into the official distribution. If you find that
> years have gone by since this code was added, and Linux isn't using
> PTRACE_GETXFPREGS, that means that our patch didn't make it, and
> you can delete this code. */
>
> Do you have PTRACE_GETXFPREGS defined in your system header files
> somewhere?
>
No.
--
H.J. Lu (hjl@gnu.org)
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Updated MAINTAINERS file - work in progress
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A4FB7F.3B87A00F@cygnus.com>
References: <200002111033.LAA29442@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00241.html
Content-length: 423
Pierre Muller wrote:
>
> At 21:33 10/02/00 -0800, you wrote:
> >> Andrew Cagney ac131313@cygnus.com?
> >> Stan Shebs shebs@cygnus.com?
>
> Wouldn't it be much more logical to have aliases here ?
>
> Andrew.Cagney@sourceware.cygnus.com
> or even better
We could. Unfortunatly it would introduce a dependence on the fsf.org
admin and they already have enough to do.
Andrew
From Stephane.Bihan@arccores.com Sat Apr 01 00:00:00 2000
From: Stephane.Bihan@arccores.com
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <OFFC5FBD39.F51E2E68-ON802568A3.00576DA1@risccores.com>
X-SW-Source: 2000-q1/msg00710.html
Content-length: 2269
>
> Stephane> I also use the breakpoint structure as an extern variable. I
> Stephane> needed it to implement the set_hw_breakpoint routine for the
> Stephane> remote protocol. I think it's not the nicer way to do but
> Stephane> ....
>
> Can you explain? I don't see any use of struct breakpoint in the
> current arc-tdep.c, nor do I see a set_hw_breakpoint function?
The version at FSF is a very old version out of date.
I am currently extending gdb for ARC to support user extensions.
>
> >> Since you say you can remove the single step code, I assume that the
> >> ISS target and remote protocol agents can perform the single step by
> >> themselves? If so, it would be advantageous to disable GDB's single
> >> step support. GDB would then issue a single "step" command instead of
> >> "insert breakpoint(s)", "continue", and "remove breakpoint(s)". The
> >> latency of a step should be greatly improved.
>
> Stephane> I will implement this for the remote target only since the
> Stephane> hardware supports single-stepping. I'm not sure if this
> Stephane> feasible in the ISS - Yuri?
>
> Stephane> If not feasible I won't disable the GDB's single step
> Stephane> support (thus enabling a call to single_step()) but I will
> Stephane> implement a single_step call to gdbstub in remote_resume().
>
> If your ISS target cannot support single step, but the remote protocol
> can, perhaps the best thing is to make software single step a target
> specific option.
By creating a target specific command?
The single step mechanism is a not a step-over-calls mechanism.
>
> I don't think that the arc is the only processor that would benefit
> from such a change. For example, the sparclet ROM monitor supports a
> single step command, but I do not know if it is ever issued because
> the SPARC target uses software single step. Perhaps it inserts the
> trap instructions needed for single step and issues the monitor step
> command?
>
> I do not think it's possible for any change to remote_resume() to be
> the right solution.
>
You're right, I've tried and if does not work.
Thanks for your explanations anyway.
Stephane.
----------------------------------------------------------------
Stephane Bihan
ARC Cores Ltd http://www.arccores.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot
2000-02-24 10:47 ` RDI target broken in 000215 snapshot Grant Edwards
@ 2000-04-01 0:00 ` Fernando Nasser
[not found] ` <20000224134607.A6354@visi.com>
0 siblings, 1 reply; 6+ messages in thread
From: Fernando Nasser @ 2000-04-01 0:00 UTC (permalink / raw)
To: Grant Edwards; +Cc: Fernando Nasser, gdb
Grant Edwards wrote:
>
> On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote:
>
> > > The RDI target support seems to be broken in the 000215
> > > snapshot.
> >
> > Can you be more specific? It is working right with the AEB board and
> > with another one I have here. Both use serial ports.
>
> (I'm now using 000222)
>
> When I download code with the "load" command, the byte order of
> the data gets flipped -- it ends up in little-endian order
> (it's big-endian in the file, and I need it to stay that way
> when it is downloaded). Downloading with a patched 4.18 doesn't
> have this problem.
>
Grant,
A few questions (while I rebuild from the 22 sources):
What compiler, in what host and with which parameters did you generate your executable file?
Is it the same one you can successifuly load with the patched 4.18?
In both cases you are loading the program into the AEB board, right?
I forgot, which host are you running gdb in? Linux, Solaris, Cygwin?
Thanks,
Fernando
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C22262.FFA0191@cygnus.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00546.html
Content-length: 1917
Jim Kingdon wrote:
>
> > Sorry, devolve, as a word, is probably more meaningful to people from
> > Commonwealth countries.
>
> I'm familiar with the word (e.g. Scotland) but at least for me it has
> all these connotations of national sovereignty and power and such.
> For example, it is a dead end to assume that an OS vendor should
> automatically maintain GDB on that OS because they "own" the platform
> or something.
>
> > The underlying concern I have isn't with people like you that have been
> > hacking on open code for years, its with people familar with GDB but not
> > so familar with open source. For that reason, I think it is useful to
> > spell out, in basic terms, how the system should work.
>
> Maybe link to The Cathedral and the Bazaar (which is well known) and
> Alan Cox's Town Council paper (which deserves to be better known and
> is at http://slashdot.org/features/98/10/13/1423253.shtml )? I was
> just showing the Town Council paper to someone in a GDB context and it
> seemed to resonate.
>
> I'm sure the looseness of this approach will make some people nervous.
> But you can't build trust through rules and policies either. What is
> going to turn GDB development into the (more) vibrant community we
> want it to be is delivering on the promises to add maintainers and
> otherwise open up. We've made great progress in the last month and
> let's keep it up.
Try this:
``
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.
If there is no maintainer for a given domain then the responsibility
falls to the head maintainer.
If there are several maintainers for a given domain then
responsibility falls to the first maintainer. The first maintainer is
free to devolve maintainership responsibility anyway they like.
Refs: http://slashdot.org/features/98/10/13/1423253.shtml
''
Andrew
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003080948.EAA16456@indy.delorie.com>
References: <200003070845.JAA27855@cerbere.u-strasbg.fr> <200003070851.DAA14463@indy.delorie.com> <14533.8241.716311.478074@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00593.html
Content-length: 2259
> This input_from_terminal_p() function does:
>
> int
> input_from_terminal_p ()
> {
> return gdb_has_a_terminal () && (instream == stdin) & caution;
> }
>
> In my case the gdb_has_a_terminal() returns 0, so the query is not asked.
>
> All seems to work fine fro solaris. What happens on DJGPP? Is
> gdb_has_a terminal() returning 1, maybe?
Yes, gdb_has_a_terminal returned 1 in the DJGPP case.
This turned to be due to a problem in ser-go32.c: it doesn't support
standard handles (those which are connected to a terminal in an
interactive session), whereas GDB expects it to.
I don't know why does gdb_has_a_terminal go through serial.c to find
out about GDB's own the controlling terminal--won't it be easier (and
more portable) just to use isatty?
Anyway, the patch to make the current code in gdb_has_a_terminal work
is below.
2000-03-07 Eli Zaretskii <eliz@is.elta.co.il>
* ser-go32.c (dos_get_tty_state): Fail if the (fake) handle was
not opened by dos_open, but let the 3 standard handles go through
unharmed.
--- gdb/ser-go32.c~0 Wed Feb 23 17:18:50 2000
+++ gdb/ser-go32.c Tue Mar 7 22:19:34 2000
@@ -488,6 +488,10 @@ dos_open (scb, name)
return -1;
}
+ /* FIXME: this is a Bad Idea (tm)! One should *never* invent file
+ handles, since they might be already used by other files/devices.
+ The Right Way to do this is to create a real handle by dup()'ing
+ some existing one. */
fd = name[3] - '1';
port = &ports[fd];
if (port->refcnt++ > 0)
@@ -650,6 +654,19 @@ dos_get_tty_state (scb)
struct dos_ttystate *port = &ports[scb->fd];
struct dos_ttystate *state;
+ /* Are they asking about a port we opened? */
+ if (port->refcnt <= 0)
+ {
+ /* We've never heard about this port. We should fail this call,
+ unless they are asking about one of the 3 standard handles,
+ in which case we pretend the handle was open by us if it is
+ connected to a terminal device. This is beacuse Unix
+ terminals use the serial interface, so GDB expects the
+ standard handles to go through here. */
+ if (scb->fd >= 3 || !isatty (scb->fd))
+ return NULL;
+ }
+
state = (struct dos_ttystate *) xmalloc (sizeof *state);
*state = *port;
return (serial_ttystate) state;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RDI target broken in 000215 snapshot
[not found] ` <38B2AD14.7B0B4A4E@redhat.com>
2000-02-24 10:47 ` RDI target broken in 000215 snapshot Grant Edwards
@ 2000-04-01 0:00 ` Grant Edwards
1 sibling, 0 replies; 6+ messages in thread
From: Grant Edwards @ 2000-04-01 0:00 UTC (permalink / raw)
To: Fernando Nasser; +Cc: gdb
On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote:
> > The RDI target support seems to be broken in the 000215
> > snapshot. I'm unable to execute any of the eCos test programs,
> > or any other applictions I've written. (they run fine with a
> > patched-up 4.18 gdb). I don't know what's wrong with it and
> > won't have time to look at it for a while.
>
> Can you be more specific? It is working right with the AEB board and
> with another one I have here. Both use serial ports.
I tried it using the ARM Embedded ICE with serial-only and with
serial-parallel interfaces. It connects to the device OK, and
I can load a file and set breakpoints, but when I type "cont",
gdb just hangs. Ctrl-C doesn't get any response, and I have to
suspend and then kill gdb. (This usually means that gdb is
waiting for a response from the JTAG interface box, and it
isn't sending anything.) The exact same sequence of operations
w/ patched 4.18 works (the program runs properly, hits the
expected breakpoint, etc.).
I haven't tried it with the EPI Jeeni.
I plan on comparing ADP packet logs to see what is different,
but this week is pretty busy and next week I'm going to be at
the Embedded Systems Conference in Chicago. So I won't get
a chance to play with it for a couple weeks.
> Please let me know what is your host machine, what version of
> tools did you use to build gdb, if on cygwin, which version of
> the dll and, last but not least, what is it that you are
> getting on the console.
Host: Linux-Intel (Vanilla RH6.1 w/ 2.2.12-20 kernel)
Gcc: egcs-2.91.66 (came w/ RH6.1)
> > Is somebody currently working on the RDI code? If so, I'll
> > leave well enough alone until the code stabilizes.
> >
> The usual folks. You, myself, Thomas, Nick, Jim... and I build and
> test it at least twice a week.
Odd.
The ADP protocol/code from ARM is pretty fragile. If the
target doesn't reply to a command, the whole thing sits there
and you have to kill gdb, reset the target, and start over.
Onee could add a receive timeout, but it won't do any good if
the JTAG interface box is hung. There's also the problem of
the two ends of the ADP connection getting frame sequence
numbers out of sync -- so there may not be a practical solution
other that the current "reset both ends and start over"
approach.
--
Grant Edwards
grante@visi.com
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: So who maintains the web pages?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bsnyxc2iy.fsf@rtl.cygnus.com>
References: <38A60492.2BB9E437@cygnus.com> <bu2jdc2mp.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00252.html
Content-length: 277
> As for what to put in MAINTAINERS, how about "anyone listed in this
> file (in any section) may have write-without-approval . . .
Oh, and if you want someone to be the "lead maintainer" or "lead
victim" or some such concept for the web pages, feel free to put me
down.
From taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Status of submitted patches? Pascal language addition patch.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002011920.OAA02797@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00087.html
Content-length: 671
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
Date: Tue, 01 Feb 2000 18:02:13 +0100
I submitted a big patch for adding Pascal Language support in GDB
already 1999/10/22.
I'm afraid that I don't remember much about the patch; nor do I have a
copy of it stashed away.
Small patches are better than big patches.
The larger the patch the longer it takes to read and evaluate -- and
it is definitely non linear. Up to a point it seems to be roughly
quadratic -- double the size of the patch and it takes maybe four
times longer to understand it.
Please resubmit the patch (against a recent snapshot) and we'll try to
do better this time around.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: blizzard@mozilla.org
Cc: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002121759.e1CHxMG02867@delius.kettenis.local>
References: <38A47E89.3F4674B3@mozilla.org>
X-SW-Source: 2000-q1/msg00244.html
Content-length: 5673
Date: Fri, 11 Feb 2000 16:26:33 -0500
From: Chris Blizzard <blizzard@mozilla.org>
Hi, folks. I've been talking about some problems that I've been
suffering through with gdb and mozilla which people on this mailing
list may or may not be aware of. Jason Molenda suggested that I
start flushing these out in the open to get some feedback on them.
I'm interested in getting my hands dirty and try to get these
problems fixed. I'm not a debugger hacker though so I might end up
asking some silly questions. :)
No problem!
May I ask some questions first? What version of GDB are you using?
What version of GCC are you using?
Here's the blurb, slightly edited for content.
...My problems are mostly related to how well gdb scales to handle
large shared libraries and large numbers of shared libraries. At
last count, there were 111 .so files in mozilla, the largest of
which is about 27 meg with debugging symbols. If you don't use
"set auto-solib-add 0" in your .gdbinit file, gdb will easily grow
to over 200 meg in size when starting the debugger. Someone once
did some estimates and it seems to use 5 times the size of a .so
after loading a shared library to debug. A lot of times, gdb won't
be able to load some of the larger .so files. It just hangs.
Let me first say that Mozilla seems to stretch things to the limit.
The huge number of shared libraries that you guys are using have
already uncovered several bugs in the dynamic linker and the Mozilla
developers have uncovered more than a few bugs in the LinuxThreads
library. That's mostly because you have gone where no one's gone
before :-)
From a quick glance at the output of `ps' on my system when loading a
program that uses about 10 shared libraries it seems that
the GDB memory usage is aproximately equal to the size of the shraed
libraries on disk. I guess the "factor 5" estimate, is referring to
the space used for debugging symbols as compared to the actual
code-size of the shared library. So it seems that your biggest
problem is the size of your shared libraries and the amount of
debugging information that's generated (which is basically
proportional to the amount of code in the libraries). I think that
using C++ is in a large way responsible for the `code bloat'. Maybe
an intelligent use of C++ features (check for compiler switches like
-fno-rtti and use them if appropriate) can reduce the size of the
resulting code. Also playing around with the options that control the
way debugging information is generated might help.
In principle the large amounts of debugging info shouldn't be a
problem. GDB can simply mmap the relevant sections, such that only
the debugging info that's really needed is actually pages in. I don't
know how the BFD library (the part of GDB that is responsible for
reading the sections containing debugging info) and the code that that
actually interprets this information implements these things. There
might be room for improvement there. Of course if all pages
containing debugging info are touched, you lose :-(.
A lot of times, trying to use "step" to step into a c++ method that
happens to be part of the same class just skips as if you had used
"next." That means that any time you want to step into a method
you have to set a temporary breakpoint by name on the method and
then allow the breakpoint to get you into that method. Doing that
to step into a dozen or so classes gets a little tedious. This is
hard to reproduce and I'm trying to build a test case.
It is a known problem that GDB has problems with the debugging output
generated by recent GCC compilers. Help in resolving those problems
would certainly be appreciated, and a (small) test case is really
essential if you want to get somebody else to look into it.
Compiling without optimization might circumvent these problems.
There are other much needed features, like not being able to
preload a .so and setting a breakpoint in the library before it
loads. Mozilla is entirely component based and this makes
debugging very, very difficult. I usually break on _dl_open in
glibc and wait until my library gets loaded before trying to set
the breakpoint that I need. That gets pretty bad after 27
libraries are loaded.
I think that the way GDB looks up symbols is differs from the way
the dynamic linker does that. That means that overriding symbols in
shared libraries probably doesn't work properly. Since the primary
use of preloaded shared libraries is overriding symbols you're likely
to experience problems. I don't think this problem is easy to solve.
Setting breakpoints in not-yet loaded shared libraries should not be
difficult to implement. Just make sure they start out as
`shlib_disabled' (see breakpoint.h) if the symbol cannot be found. It
is necessary to introduce a new command to do this (suggested name
`shlib-break' or `solib-break'). Reusing the guts of the ordinary
breakpoint setting command should be possible.
There are also various problems with threads. A lot of times gdb
won't exit after the last thread exits because it keeps trying to
kill a process which doesn't exist any more.
Probably caused by the strange way threads interact with signals on
Linux. It's very likely that the real bug is in the LinuxThreads
library and not in GDB. A lot of LinuxThreads problems have recently
been solved. You might want to try the latest glibc 2.1.3
pre-release. Or have a little patience, glibc 2.1.3 is supposed to be
released real soon now.
Hope this helps, and I'm looking forward to your contributions :-),
Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>
Cc: gdb@sourceware.cygnus.com
Subject: Re: copyright banner and reporting bugs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DF418A.42355DAD@cygnus.com>
References: <38CFF922.6BA6928E@redhat.co.uk>
X-SW-Source: 2000-q1/msg00817.html
Content-length: 547
Jonathan Larmour wrote:
>
> I just noticed two minor things: surely the copyright banner when GDB starts
> should be something more recent than 1998 even now - i.e. it shouldn't need
> to wait for the release.
Good point. It should pick up Makefile.in:VERSION.
> Also on http://sourceware.cygnus.com/gdb it isn't at all clear how users
> report bugs. This is worthy of a section in its own right surely! Just an
> appropriate regurgitation of the info file node from gdb.texinfo would be
> enough.
I've updated it. Feedback welcome.
Andrew
From velco@fadata.bg Sat Apr 01 00:00:00 2000
From: Momchil Velikov <velco@fadata.bg>
To: GDB List <gdb@sourceware.cygnus.com>
Subject: Remote debugging over UDP
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DFABC7.A884D5D7@fadata.bg>
X-SW-Source: 2000-q1/msg00825.html
Content-length: 362
Hi,
I have added support for debugging remote targets
over UDP ("added support", that's cloned ser-tcp.c and tweaked it
a little bit).
Are interested in including that in GDB ?
Do you mind changing the syntax the parameter NAME to
serial.c:serial_open () to
tcp:<host>:<port>, and
udp:<host>:<port>
for TCP and UDP connections, respectively ?
Regards,
-velco
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: kingdon@redhat.com (Jim Kingdon)
Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Regression caused by elfread.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002150800.AAA07477@alabama.wrs.com>
References: <200002150453.XAA11268@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00289.html
Content-length: 1928
> I don't see how your patch could work at all - sym->section->index is
> a very different number than a SECT_OFF_* code. The SECT_OFF_* code
In case it interests anyone, I spent most of January figuring out how to teach
GDB how to let both cases coexist properly. It is my considered opinion that
the SECT_OFF_* machinery really only works when all the offsets are the same.
However, so few configurations (read: vxWorks and ??) actually use different
offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the
problems with it. (We read relocatable .o files too, which is also rare.)
Our particular bug is as follows: for a.out, read-only data gets put into
.text, but the stabs generated are indistinguishable (or prohibitively hard
to distinguish, anyway) from a non-const version of the same item which gets
put into .data. Thus it is impossible to find the correct address without
using actual relocation records. (The same bug occurs on ELF although in
this case it is because .rodata is classed as a text section by our loader,
which then feeds us a single address for the group of text sections. sigh)
One of our consultants developed code for ELF/DWARF relocatables which
actually calls bfd_final_link_relocate to process reloc info, because in
the DWARF case we have even less information to tell things apart than with
stabs. I extended that to do full final address relocation and worked out
how to have struct section_offsets keep track of what is going on, so that
ANOFFSET can be replaced with a variety of different macros depending on
what usage is intended. (This also allowed optional asserts to be compiled
in, which turned out to be helpful once I started testing, and illuminated
a few cases too.)
A gutted tarball of 4.17+local sources is temporarily available (in an
execute-only directory) at:
ftp://ftp.toddpw.org/private/vxgdb.tar.bz2
--
Todd Whitesel
toddpw @ windriver.com
From davea@dsl-quasar.corp.sgi.com Sat Apr 01 00:00:00 2000
From: davea@dsl-quasar.corp.sgi.com (David B. Anderson)
To: gdb@sourceware.cygnus.com
Subject: Re: mdebug
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312258.OAA25181@dsl-quasar.corp.sgi.com>
X-SW-Source: 2000-q1/msg00847.html
Content-length: 1092
Elena Zannoni <ezannoni@cygnus.com> writes:
>Does anybody know something about mdebug?
Yes.
>I am trying to figure out a problem in gdb which untilmately is due
>to some limitation of mdebug.
>Is there any documentation at all about how the debug symbols are built?
http://reality.sgi.com/davea/objectinfo.html
Look early in the page for:
one part of the old 32bit ABI for MIPS
is the mdebug debugging information.
A postscript file with the only currently
available description of this data is here (119Kbytes)
It is is an old paper I wrote on mdebug.
Not too well written, but... what else is there?
Perhaps it will help. Does not mention limits, though.
The limits are implicit in various structs. Perhaps
'explicit' is a better word :-)
If you have any questions let me know.
(whether I'll know the answer is something else...)
I don't know too much about DEC or other *extensions*
to mdebug. Just sgi's. But there are certainly some
important limitations in mdebug. Like 64K procedures (at most).
SGI did some hack extensions, but ... never mind.
davea@sgi.com
From srikanth@cup.hp.com Sat Apr 01 00:00:00 2000
From: Srikanth <srikanth@cup.hp.com>
To: Chris Blizzard <blizzard@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AB3457.6902@cup.hp.com>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com>
X-SW-Source: 2000-q1/msg00315.html
Content-length: 4577
Chris Blizzard wrote:
>
> So, one of the problems that I've been having is that some large .so libraries
> take forever to load. One of the libraries is about 28 meg with debugging
> symbols in it. I've let it run for about 10 mins and it's never finished
> loading. Here's what gprof says for loading a reasonable sized library ( 5
> meg or so ):
>
> Flat profile:
>
> Each sample counts as 0.01 seconds.
> % cumulative self self total
> time seconds seconds calls ms/call ms/call name
> 70.98 19.47 19.47 11954 1.63 2.25 lookup_minimal_symbol
> 27.12 26.91 7.44 33240213 0.00 0.00 strcmp_iw
> 0.33 27.00 0.09 3 30.00 9038.95 read_dbx_symtab
> 0.15 27.04 0.04 44554 0.00 0.00 hash
> 0.11 27.07 0.03 337915 0.00 0.00 bfd_getl32
> 0.11 27.10 0.03 44554 0.00 0.00 bcache
> 0.11 27.13 0.03 150 0.20 0.20 end_psymtab
>
> Uhh...that's 33 _million_ calls. That looks like this chunk of code:
>
> for (objfile = object_files;
> objfile != NULL && found_symbol == NULL;
> objfile = objfile->next)
> {
> if (objf == NULL || objf == objfile)
> {
> for (msymbol = objfile->msymbols;
> msymbol != NULL && SYMBOL_NAME (msymbol) != NULL &&
> found_symbol == NULL;
> msymbol++)
> {
> if (SYMBOL_MATCHES_NAME (msymbol, name))
> {
> switch (MSYMBOL_TYPE (msymbol))
> {
> case mst_file_text:
>
> I'm sorry, is that looking over a linked list? SYMBOL_MATCHES_NAME() is a
> macro that does some mangling magic so we can't use a standard hash lookup
> table but there has to be something we can do to speed that up.
>
> --Chris
>
We at HP have been running into many of these issues
and have substantially re-architected the symbol table management
to achieve performance. Here are some of the things we did :
(1) The function lookup_minimal_symbol believe it or
not performs linear search. The minimal symbol table is sorted
by the symbol address and not by name, so binary searches are
possible in lookup_minimal_symbol_by_pc but not in
lookup_minimal_symbol ()
The difficulty here is that a name lookup could be
based on either a demangled name or a mangled name. So unless we
sort the table by both we will have to do linear search. Sorting
the table by both involves heavy penalty at startup, as that
entail three sorts with different keys (PC, demangled name and
mangled name). We eliminated one of the keys : the demangled name
and do a double sort.
(2) Just in time demangling : Rightnow, gdb demangles
the linker symbol table at startup. This simply does not scale
well to large applications. We implemented a scheme by which we
eliminate all anticipatory demangling and do it just in time, only
for the set of symbols the user refers to in a debugging session.
Other than the "minimal" symbol table, there could be other
spots where whole scale anticipatory demangling could be going
on : in build_psymtabs() etc ... Avoiding anticipatory demangling
allowed us to eliminate one of the sort keys for (1) above. This
may or may not be possible to do with your compiler.
(3) GDB internalizes the native debugging information
in its entirety. Studies show a "typical" debugging session
uses less than 15% all debug info from a binary.
(4) For C++, it is very likely the linker (minimal)
symbol table contains all kinds of compiler generated symbols
for such things like vtables, exception handling, RTTI etc.
Also based on your compiler, last of internal symbols generated
for the purpose of relocation could be making their way into
the linker symbol table. Do a maint print msymbols <filename>
and take a look for symbols that don't look like user space
symbols. Some of these symbols are crucial for gdb ro interact
properly with the runtime. But there could be others....
(5) The bcache could be extremely expensive in some platforms.
What this module does is to try to eliminate duplicates in
debug info. Some platforms (like HP) eliminate all (most)
redundancy in the debug info in a hidden linker pass. For HP
we simply disconnected the bcache and saw a 50% improvement in
memory and 20% or so performance improvement.
(6) Compilers could be emitting too much debug info
than is necessary. Some compilers try to be optimal but some
don't.
Hope this is helpful.
Srikanth
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com, drepper@cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CEE0DD.11A@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com> <38CEDB3E.DA17FA9A@cygnus.com>
X-SW-Source: 2000-q1/msg00705.html
Content-length: 472
Andrew Cagney wrote:
>
> Michael Snyder wrote:
>
> > As far as I can tell, yes it did.
> > This is something that the thread_db implementation was
> > designed to handle -- I just didn't get around to it.
> > I hope to be able to fit it in "real soon now".
>
> So this effectivly means that this particular thread problem is a ``nice
> to have'' rather than a ``must have'' for 5.0.
>
> Something that can be better easier fixed in the 5.1 timeframe.
I would say so.
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: Re: memory region attribute CLI
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m3dplwjri.fsf@jtc.redbacknetworks.com>
References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00745.html
Content-length: 11575
>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
jtc> Yes, I guess it has been a while, hasn't it.
jtc>
jtc> Start at:
jtc> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00168.html
No comments?
Here's a bit more meat. I've gone ahead and implemented the CLI, and
would appreciate any comments. I'm planning on writing documentation
and making the changes to use these attributes this week.
Many thanks,
--jtc
/* memattr.h */
#ifndef MEMATTR_H
#define MEMATTR_H
/* FIXME: I stole this bit from tracepoint.h. The definition should
probably be moved out of breakpoint.h, tracepoint.h, and memattr.h
and into defs.h or something like that. */
#if !defined (BREAKPOINT_H)
enum enable
{
disabled, enabled
};
#endif
enum mem_access_mode
{
MEM_RW, /* read/write */
MEM_RO, /* read only */
MEM_WO, /* write only */
};
enum mem_access_width
{
MEM_WIDTH_UNSPECIFIED,
MEM_WIDTH_8, /* 8 bit accesses */
MEM_WIDTH_16, /* 16 " " */
MEM_WIDTH_32, /* 32 " " */
MEM_WIDTH_64 /* 64 " " */
};
/* The set of all attributes that can be set for a memory region.
This structure was created so that memory attributes can be passed
to target_ functions without exposing the details of memory region
list, which would be necessary if these fields were simply added to
the mem_region structure.
FIXME: It would be useful if there was a mechanism for targets to
add their own attributes. For example, the number of wait states. */
struct mem_attrib
{
/* read/write, read-only, or write-only */
enum mem_access_mode mode;
enum mem_access_width width;
/* enables hardware breakpoints */
int hwbreak;
/* enables host-side caching of memory region data */
int cache;
/* enables memory verification. after a write, memory is re-read
to verify that the write was successful. */
int verify;
};
struct mem_region
{
/* FIXME: memory regions are stored in an unsorted singly-linked
list. This probably won't scale to handle hundreds of memory
regions --- that many could be needed to describe the allowed
access modes for memory mapped i/o device registers. */
struct mem_region *next;
CORE_ADDR lo;
CORE_ADDR hi;
/* Item number of this memory region. */
int number;
/* Status of this memory region (enabled or disabled) */
int status;
/* Attributes for this region */
struct mem_attrib attrib;
};
extern struct mem_region *lookup_mem_region(CORE_ADDR);
#endif /* MEMATTR_H */
/* memattr.c */
#include "defs.h"
#include "command.h"
#include "gdbcmd.h"
#include "memattr.h"
#include "gdb_string.h"
const struct mem_attrib default_mem_attrib =
{
MEM_RW, /* mode */
MEM_WIDTH_UNSPECIFIED,
false, /* hwbreak */
false, /* cache */
false /* verify */
};
static struct mem_region *mem_region_chain = NULL;
static mem_number = 0;
static struct mem_region *
create_mem_region (CORE_ADDR lo, CORE_ADDR hi,
const struct mem_attrib *attrib)
{
struct mem_region *n, *p, *new;
if (lo > hi) {
printf_unfiltered ("invalid memory region\n");
return NULL;
}
n = mem_region_chain;
while (n) {
/* overlapping node */
if ((lo >= n->lo && lo <= n->hi) ||
(hi >= n->lo && hi <= n->hi))
{
printf_unfiltered ("overlapping memory region\n");
return NULL;
}
}
new = xmalloc (sizeof (struct mem_region));
new->lo = lo;
new->hi = hi;
new->number = ++mem_number;
new->status = enabled;
new->attrib = *attrib;
/* link in new node */
new->next = mem_region_chain;
mem_region_chain = new;
return new;
}
static void
delete_mem_region(struct mem_region *m)
{
free(m);
}
struct mem_region *
lookup_mem_region(CORE_ADDR addr)
{
struct mem_region *m;
for (m = mem_region_chain; m; m = m->next) {
if (addr >= m->lo && addr <= m->hi)
return m;
}
return NULL;
}
\f
static void
mem_command (char *args, int from_tty)
{
CORE_ADDR lo, hi;
char *tok;
struct mem_attrib attrib;
if (!args)
error_no_arg("No mem");
tok = strtok(args, " \t");
if (!tok)
error("no lo address");
lo = parse_and_eval_address(tok);
tok = strtok(NULL, " \t");
if (!tok)
error("no hi address");
hi = parse_and_eval_address(tok);
attrib = default_mem_attrib;
while ((tok = strtok (NULL, " \t")) != NULL)
{
if (strcmp (tok, "rw") == 0)
attrib.mode = MEM_RW;
else if (strcmp (tok, "ro") == 0)
attrib.mode = MEM_RO;
else if (strcmp (tok, "wo") == 0)
attrib.mode = MEM_WO;
else if (strcmp (tok, "8") == 0)
attrib.width = MEM_WIDTH_8;
else if (strcmp (tok, "16") == 0)
{
if ((lo % 2 != 0) || (hi % 2 != 0))
error ("region bounds not 16 bit aligned");
attrib.width = MEM_WIDTH_16;
}
else if (strcmp (tok, "32") == 0)
{
if ((lo % 4 != 0) || (hi % 4 != 0))
error ("region bounds not 32 bit aligned");
attrib.width = MEM_WIDTH_32;
}
else if (strcmp (tok, "64") == 0)
{
if ((lo % 8 != 0) || (hi % 8 != 0))
error ("region bounds not 64 bit aligned");
attrib.width = MEM_WIDTH_64;
}
else if (strcmp (tok, "hwbreak") == 0)
attrib.hwbreak = true;
else if (strcmp (tok, "swbreak") == 0)
attrib.hwbreak = false;
else if (strcmp (tok, "cache") == 0)
attrib.cache = true;
else if (strcmp (tok, "nocache") == 0)
attrib.cache = false;
else if (strcmp (tok, "verify") == 0)
attrib.verify = true;
else if (strcmp (tok, "noverify") == 0)
attrib.verify = false;
else
error ("unknown attribute: %s", tok);
}
create_mem_region(lo, hi, &attrib);
}
\f
static void
mem_info_command (char *args, int from_tty)
{
struct mem_region *m;
struct mem_attrib *attrib;
if (!mem_region_chain)
{
printf_unfiltered ("There are no memory regions defined.\n");
return;
}
printf_filtered ("Memory regions now in effect:\n");
for (m = mem_region_chain; m; m = m->next)
{
printf_filtered ("%d: %c\t",
m->number,
m->status ? 'y' : 'n');
printf_filtered ("%s - ",
local_hex_string_custom ((unsigned long) m->lo, "08l"));
printf_filtered ("%s\t",
local_hex_string_custom ((unsigned long) m->hi, "08l"));
/* Print a token for each attribute.
*
* FIXME: Should we output a comma after each token? It may
* make it easier for users to read, but we'd lose the ability
* to cut-and-paste the list of attributes when defining a new
* region. Perhaps that is not important.
*
* FIXME: If more attributes are added to GDB, the output may
* become cluttered and difficult for users to read. At that
* time, we may want to consider printing tokens only if they
* are different from the default attribute.
*/
attrib = &m->attrib;
switch (attrib->mode)
{
case MEM_RW:
printf_filtered ("rw ");
break;
case MEM_RO:
printf_filtered ("ro ");
break;
case MEM_WO:
printf_filtered ("wo ");
break;
}
switch (attrib->width)
{
case MEM_WIDTH_8:
printf_filtered ("8 ");
break;
case MEM_WIDTH_16:
printf_filtered ("16 ");
break;
case MEM_WIDTH_32:
printf_filtered ("32 ");
break;
case MEM_WIDTH_64:
printf_filtered ("64 ");
break;
case MEM_WIDTH_UNSPECIFIED:
break;
}
if (attrib->hwbreak)
printf_filtered ("hwbreak");
else
printf_filtered ("swbreak");
if (attrib->cache)
printf_filtered ("cache ");
else
printf_filtered ("nocache ");
if (attrib->verify)
printf_filtered ("verify ");
else
printf_filtered ("noverify ");
printf_filtered ("\n");
gdb_flush (gdb_stdout);
}
}
\f
/* Enable the memory region number NUM. */
static void
mem_enable (int num)
{
struct mem_region *m;
for (m = mem_region_chain; m; m = m->next)
if (m->number == num)
{
m->status = enabled;
return;
}
printf_unfiltered ("No memory region number %d.\n", num);
}
static void
mem_enable_command (char *args, int from_tty)
{
char *p = args;
char *p1;
int num;
struct mem_region *m;
if (p == 0)
{
for (m = mem_region_chain; m; m = m->next)
m->status = enabled;
}
else
while (*p)
{
p1 = p;
while (*p1 >= '0' && *p1 <= '9')
p1++;
if (*p1 && *p1 != ' ' && *p1 != '\t')
error ("Arguments must be memory region numbers.");
num = atoi (p);
mem_enable (num);
p = p1;
while (*p == ' ' || *p == '\t')
p++;
}
}
\f
/* Disable the memory region number NUM. */
static void
mem_disable (int num)
{
struct mem_region *m;
for (m = mem_region_chain; m; m = m->next)
if (m->number == num)
{
m->status = disabled;
return;
}
printf_unfiltered ("No memory region number %d.\n", num);
}
static void
mem_disable_command (char *args, int from_tty)
{
char *p = args;
char *p1;
int num;
struct mem_region *m;
if (p == 0)
{
for (m = mem_region_chain; m; m = m->next)
m->status = disabled;
}
else
while (*p)
{
p1 = p;
while (*p1 >= '0' && *p1 <= '9')
p1++;
if (*p1 && *p1 != ' ' && *p1 != '\t')
error ("Arguments must be memory region numbers.");
num = atoi (p);
mem_disable (num);
p = p1;
while (*p == ' ' || *p == '\t')
p++;
}
}
/* Clear memory region list */
static void
mem_clear (void)
{
struct mem_region *m;
while ((m = mem_region_chain) != 0)
{
mem_region_chain = m->next;
delete_mem_region(m);
}
}
/* Delete the memory region number NUM. */
static void
mem_delete(int num)
{
struct mem_region *m1, *m;
if (!mem_region_chain)
printf_unfiltered ("No memory region number %d.\n", num);
if (mem_region_chain->number == num)
{
m1 = mem_region_chain;
mem_region_chain = m1->next;
delete_mem_region(m1);
}
else
for (m = mem_region_chain; m->next; m = m->next)
{
if (m->next->number == num)
{
m1 = m->next;
m->next = m1->next;
delete_mem_region(m1);
break;
}
}
printf_unfiltered ("No memory region number %d.\n", num);
}
static void
mem_delete_command (char *args, int from_tty)
{
char *p = args;
char *p1;
int num;
if (p == 0)
{
if (query ("Delete all memory regions? "))
mem_clear();
dont_repeat();
return;
}
while (*p)
{
p1 = p;
while (*p1 >= '0' && *p1 <= '9')
p1++;
if (*p1 && *p1 != ' ' && *p1 != '\t')
error ("Arguments must be memory region numbers.");
num = atoi (p);
mem_delete (num);
p = p1;
while (*p == ' ' || *p == '\t')
p++;
}
dont_repeat();
}
_initialize_mem ()
{
add_com ("mem", class_vars, mem_command,
"Define attributes for memory region.");
add_cmd ("mem", class_vars, mem_enable_command,
"Enable memory region.\n\
Arguments are the code numbers of the memory regions to enable.\n\
Do \"info mem\" to see current list of code numbers.", &enablelist);
add_cmd ("mem", class_vars, mem_disable_command,
"Disable memory region.\n\
Arguments are the code numbers of the memory regions to disable.\n\
Do \"info mem\" to see current list of code numbers.", &disablelist);
add_cmd ("mem", class_vars, mem_delete_command,
"Delete memory region.\n\
Arguments are the code numbers of the memory regions to delete.\n\
Do \"info mem\" to see current list of code numbers.", &deletelist);
add_info ("mem", mem_info_command,
"Memory region attributes");
}
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Robert Lipe <robertl@sco.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: config.guess version regression
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B31515.73EA86EB@cygnus.com>
References: <20000222151535.A23483@rjlhome.sco.com>
X-SW-Source: 2000-q1/msg00374.html
Content-length: 1060
Robert Lipe wrote:
>
> I suspect this is a result of the repository shuffling in recent weeks,
> but the top-level config.guess went back several versions. This means
> that some later OSes (i586-sco-sysv5uw7.1.1 in my case) is no longer
> automatically recognized.
FYI, getting config.guess updated is on my 5.0 hit list.
> Should I submit an explicit patch to resync it against the one in
> autoconf or can someone with CVS accesses to both just plunk a new
> version in? If this is considered too radical, I suppose we can fish
> for the config.guess that lived in gdb before the big restructuring.
I'ts not at all radical :-) I've already done a heads up on the
binutils side. I've just got to push the keys :-)
Franz Sirl wrote:
> Please don't sync with autoconf, it's currently outdated. Either sync with the
> master repository "cvs -d :pserver:anoncvs@subversions.gnu.org:/home/cvs
> co config" or use the one in GCC, which I synced last week. Ah, and don't
> forget to sync both config.guess and config.sub.
thanks for this pointer
Andrew
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: gdb@sourceware.cygnus.com
Subject: RTTI working for G++
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003131601500.8750-100000@localhost.localdomain>
X-SW-Source: 2000-q1/msg00692.html
Content-length: 3476
Okay, i have RTTI working for g++.
Well, all except for multiple inheritance.
Scratch that last part, i just made it offset properly if you have >1
baseclass, so al is good.
If i could have one or two volunteers to make sure it's not just my setup,
and that all is well, before i post the patches asking for comments, i'd
appreciate it.
In any case, let me know what you guys think of it so far.
If you look at the output, you'll notice that while for printing, it will
print the object as if it was it's derived type, when it comes to
accessing members/methods, just like in C++, you can't access the members,
unless you specifically cast it to that derived type.
For those wondering what the patch will do, check this out:
The inheritance on these classes in the example looks like this
fred is a base
dan and bob both inherit directly from fred.
george is another base.
george2 inherits from george and bob (public george, public bob)
I'll rename them so they make more sense as i work up testcases.
But anyway, here's some output:
GNU gdb 20000204
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsdelf4.0".
Setting up the environment for debugging gdb.
.gdbinit:5: Error in sourced command file:
No symbol table is loaded. Use the "file" command.
(gdb) file a.out
Reading symbols from a.out...done.
(gdb) b main
Breakpoint 1 at 0x8048918: file a.cc, line 29.
(gdb) set print object on
(gdb) set print pretty on
(gdb) set print vtbl on
(gdb) set print array on
(gdb) r
Starting program: /usr/local/gdb/src/gdb/a.out
Breakpoint 1, 0x8048918 in main () at a.cc:29
29 {
(gdb) n
31 dan=new daniel();
(gdb) n
32 cout <<typeid(*dan).name()<<endl;
(gdb) p dan
$1 = (daniel *) 0x8051030
(gdb) p dan[0]
$2 = (daniel) {
<fred> = {
a = 0,
_vptr$ = 0x804f390
},
members of daniel:
b = 0
}
(gdb) ptype dan
type = class fred {
public:
int a;
fred & operator=(fred const &);
fred(fred const &);
fred(void);
virtual int ab(void);
} *
(gdb) p dan[0]->b
There is no member or method named b.
(gdb) n
6daniel
33 dan=new bob();
(gdb)
34 dan=new george2();
(gdb) p dan
$3 = (bob *) 0x8051040
(gdb) p dan[0]
$4 = (bob) {
<fred> = {
a = 0,
_vptr$ = 0x804f378
},
members of bob:
c = 0
}
(gdb) p dan[0].c
There is no member or method named c.
(gdb) n
35 dan->a=55;
(gdb) p dan[0]
$5 = (george2 [incomplete object]) {
<george> = {
d = 0
},
<bob> = {
<fred> = {
a = 0,
_vptr$ = 0x804f360
},
members of bob:
c = 0
},
members of george2:
e = 0
}
(gdb) l
30 fred *dan;
31 dan=new daniel();
32 cout <<typeid(*dan).name()<<endl;
33 dan=new bob();
34 dan=new george2();
35 dan->a=55;
36 cout <<typeid(*dan).name()<<endl;
37 }
38
(gdb) n
36 cout <<typeid(*dan).name()<<endl;
(gdb) p dan
$7 = (suspicious *) 0x8050064
(gdb) p dan[0]
$8 = (george2 [incomplete object]) {
<george> = {
d = 0
},
<bob> = {
<fred> = {
a = 55,
_vptr$ = 0x804f360
},
members of bob:
c = 0
},
members of george2:
e = 0
}
(gdb) c
Continuing.
7george2
Program exited normally.
(gdb) q
Script done on Mon Mar 13 19:34:51 2000
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20000221104541.A28578@visi.com>
[not found] ` <38B2AD14.7B0B4A4E@redhat.com>
2000-02-24 10:47 ` RDI target broken in 000215 snapshot Grant Edwards
2000-04-01 0:00 ` Fernando Nasser
[not found] ` <20000224134607.A6354@visi.com>
2000-02-24 12:01 ` Fernando Nasser
[not found] ` <38B59CE1.4CFA7F1E@cygnus.com>
[not found] ` <20000224152638.A2092@visi.com>
[not found] ` <38B5EEDB.8A8F2DD8@cygnus.com>
2000-04-01 0:00 ` Grant Edwards
[not found] ` <38B61CF6.B4F80802@cygnus.com>
[not found] ` <38B69A2A.ED2DC6F3@redhat.com>
2000-04-01 0:00 ` Grant Edwards
2000-04-01 0:00 ` Grant Edwards
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox