* Re: [aeb] Re: GNU toolchain and AEB
[not found] <Pine.LNX.4.31.0101171542280.22162-100000@www.cgsoftware.com>
@ 2001-01-17 13:04 ` Jens-Christian Lache
0 siblings, 0 replies; only message in thread
From: Jens-Christian Lache @ 2001-01-17 13:04 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 43812 bytes --]
Thank´s! Fernando just mailed me the path:
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.15
diff -c -w -r1.15 symtab.c
*** symtab.c 2000/09/04 08:29:25 1.15
--- symtab.c 2001/01/12 19:29:21
***************
*** 754,760 ****
{
/* This is a mangled variable, look it up by its
mangled name. */
! return lookup_symbol (SYMBOL_NAME (msymbol), block,
namespace, is_a_field_of_this,
symtab);
}
/* There are no debug symbols for this file, or we are looking
--- 754,760 ----
{
/* This is a mangled variable, look it up by its
mangled name. */
! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
namespace, is_a_field_of_this,
symtab);
}
/* There are no debug symbols for this file, or we are looking
This patch was just on the gdb-patch list, right?
I ´ ll give it a try tomorow, it is already 17 22:00:03 CET 2001
in HH and my eyes are like rectangels!
Best regards!
Jens-Christian
Am Mit, 17 Jan 2001 schrieben Sie:
> This is the same infinite recursion bug that we need approval for
> committing. When approval is given, it will be committed, and the bug will
> be fixed.
> Look at gdb-patches for a recent message from Jim Ingham for the most
> recent patch for this bug, and apply. It's been pissing people off for
> over a month
> now, but there is little that can be done, as their is no obvious bugfix
> rule, as there in in gcc.
> --Dan
>
>
> On Wed, 17 Jan 2001, Jens-Christian Lache wrote:
>
> > Hi Fernando! Could you reproduce the problem?
> > I really could need a "working" debugger! I have seen the bug described below
> > not only in the toolstips, but also while trying to watch objects.
> >
> > > Hi everybody!
> > > This is a bug report about:
> > >
> > > Today I encounter a problem with the gdb. I had the tooltips for variables
> > > turned on. When moving the mousepointer over a field of a class, gdb startet to
> > > allocote ruff amounts of mem. Only the limit of 128MB of swap could stop
> > > it, it crashed and my X crashed too. I could mail you the project
> > > and explain you how to reproduce this error.
> > >
> > > This is how to reproduce it:
> > >
> > > 1.) install & say "make" in the adeos dir
> > > 2.) download & start it to a AT91EB01 or AT91EB40
> > > It will stop in "main" at "os.start();"
> > > 3.) set a breakpoint in sched.cpp, function "Sched::start(void)",
> > > third line "schedule();"
> > > 4.) continue
> > > 5.) move mousepointer over "state" from the line above
> > > "state = Started;" Having
> > > tooltips turned on, it should crash. Or try to add it to the list of
> > > watch exprecions.
> > >
> > > My arm-elf-gdb is from 20001212.
> > >
> > > Regards,
> > >
> > > Jens-Christian
> > >
> > > Am Don, 11 Jan 2001 schrieben Sie:
> > > > Jens-Christian Lache wrote:
> > > > >
> > > > > > Yes this sounds serious. But I guess I know that it is caused by a
> > > > > > bug in the C++ symbol handling in GDB. It gets into an infinite loop
> > > > > > when we are looking for an overloaded symbol (I don't know the
> > > > > > exact circunstances).
> > > > > >
> > > > > > Someone has been fixing C++ things lately. Have you tried getting the
> > > > > > latest insight from CVS to see if it works better for you?
> > > > > Could you be a little more precise about lately? Mine is from 20001212.
> > > >
> > > > Jee! That sounds new enough.
> > > >
> > > > I guess I will have to take you on your offer to try to reproduce it.
> > > >
> > > > What I am going to do is to try and find someone from the GDB C++ area
> > > > to look at it. I myself have not played with that code for a while and
> > > > I am full of GUI stuff to do.
> > > >
> > > > I have seem a similar problem, so I will bug them with this one as well.
> > > > Lets hope they find it fast.
> > > >
> > > > Maybe you should turn off your variable ballons in the meanwhile to
> > > > avoid accidentaly
> > > > tripping over one of those classes. There is a preference under
> > > > Preferences->Source
> > > > to turn them off.
> > > >
> > > >
> > > > > Thank´s again for your great support, :-)
> > > > >
> > > > You're welcome.
> > > >
> > > >
> > > > P.S.: Can you post your messages to the list? We use the archives as a
> > > > knowledge base
> > > > so if other people have a similar problem they can use our
> > > > findings by searching
> > > > the old messages. Also, sometimes there are other people who
> > > > know something
> > > > about the problem we are tracking down and they can jump in and
> > > > help us.
> > > > :-)
> > > >
> > > >
> > > > --
> > > > Fernando Nasser
> > > > Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
> > > > 2323 Yonge Street, Suite #300
> > > > Toronto, Ontario M4P 2C9
> > > --
> > >
> > >
> > > Jens-Christian Lache
> > > Technische Universitaet Hamburg-Harburg
> > > www.tu-harburg.de/~sejl1601
> > > Mail:
> > > lache@tu-harburg.de
> > > lache@ngi.de
> > > Tel.:
> > > +0491759610756
> > >
> >
> > ----------------------------------------
> > Content-Type: application/x-gzip; name="adeos.tgz"
> > Content-Transfer-Encoding: base64
> > Content-Description:
> > ----------------------------------------
> >
> > --
> >
> >
> > Jens-Christian Lache
> > Technische Universitaet Hamburg-Harburg
> > www.tu-harburg.de/~sejl1601
> > Mail:
> > lache@tu-harburg.de
> > lache@ngi.de
> > Tel.:
> > +0491759610756
> >
--
Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
From cgf@redhat.com Wed Jan 17 13:54:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: gdb test results web page
Date: Wed, 17 Jan 2001 13:54:00 -0000
Message-id: <20010117165403.A15748@redhat.com>
X-SW-Source: 2001-01/msg00116.html
Content-length: 727
I've been meaning to announce the existence of the gdb test results web
page for some time. It is here:
http://sources.redhat.com/cgi-bin/gdb.cgi
This web page uses some cool software, written by Tom Tromey that helps
in the categorization and comparison of test results. You can upload
your own test results here by clicking on the "upload a testsuite log
file" link or by sending email to gdb-testresults@sources.redhat.com.
We're thinking of setting up a project on sources.redhat.com devoted to
the "Terf" software which handles this web page so that people can
improve it. If anyone is interested in joining this project let me
know. You'll need to be fairly proficient in perl, since Terf is written
in perl.
cgf
From chastain@cygnus.com Wed Jan 17 14:48:00 2001
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: cgf@redhat.com, gdb@sources.redhat.com
Subject: Re: gdb test results web page
Date: Wed, 17 Jan 2001 14:48:00 -0000
Message-id: <200101172246.OAA07607@bosch.cygnus.com>
X-SW-Source: 2001-01/msg00117.html
Content-length: 1066
It looks promising, but I think it's not usable yet.
The upload page says:
UPLOAD FOR GDB
Enter the file name of a test suite log file to upload:
--------------------------------------------------------
| |
--------------------------------------------------------
So I gave it my "gdb.log" file for 2001-01-15.
Now the results page says there were 375 PASS, 7 FAIL, 0 XPASS, and 0 XFAIL
for this test run. That's way too few total tests.
It appears that the results page counts only results that start in
column 1. That's fine for "gdb.sum" files, but it misses 90% of the
results in "gdb.log" files. It looks like every entry in the current
database suffers from this problem.
The upload page should say more clearly whether it wants a "gdb.log"
file or a "gdb.sum" file. And if it does not handle both types, then
it needs to reject files of the wrong type.
I have a lot more opinions but I better shut up before I get recruited!
Michael Chastain
<chastain@redhat.com>
"love without fear"
From chienyul@yahoo.com Wed Jan 17 15:01:00 2001
From: Jeremy Lin <chienyul@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: Using gdb with JEENI
Date: Wed, 17 Jan 2001 15:01:00 -0000
Message-id: <20010117230125.9518.qmail@web2304.mail.yahoo.com>
X-SW-Source: 2001-01/msg00118.html
Content-length: 1519
I have a problem using JEENI with GDB 5.0 debugging.
JEENI FirmwareVersion:2.0
Connected via serial port and RDI(tar rdi s=com2),
I'm doing the eCos porting to our customize board based on
Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging
the ROM image which initialize the board. The problem is, for example,
here is a sample instructions of the ROM image dump by gnu objdump:
00008060 <reset_vector>:
8060: e59f0458 ldr r0, [pc, #458]
8064: e5800000 str r0, [r0]
00008068 <warm_reset>:
8068: e3a00000 mov r0, #0 ; 0x0
806c: e5800040 str r0, [r0, #64]
8070: e59f144c ldr r1, [pc, #44c]
8074: e5912008 ldr r2, [r1, #8]
8078: e5802008 str r2, [r0, #8]
807c: e5912040 ldr r2, [r1, #64]
8080: e5802028 str r2, [r0, #40]
8084: ef000000 swi 0x00000000
when I set a breakpoint"b *0x8070" then "continue", it breaks
normally. But after that I type "stepi" to run next instruction.
This message comes out and gdb was terminated:
0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \
STATUS_ACCESS_VIOLATION
21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to
arm-elf-gdb.exe.stack.dump
Segmentation fault (core dump)
This happens also when I set the 2nd breakpoint (for example, at 0x8080) and
enter "continue". So I can only set one breakpoint at a time...
Does any one have the same problem?
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
From fnasser@cygnus.com Wed Jan 17 15:08:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Jeremy Lin <chienyul@yahoo.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Using gdb with JEENI
Date: Wed, 17 Jan 2001 15:08:00 -0000
Message-id: <3A662600.FE7C0AEC@cygnus.com>
References: <20010117230125.9518.qmail@web2304.mail.yahoo.com>
X-SW-Source: 2001-01/msg00119.html
Content-length: 1958
Which version of Cygwin are you using?
Jeremy Lin wrote:
>
> I have a problem using JEENI with GDB 5.0 debugging.
> JEENI FirmwareVersion:2.0
> Connected via serial port and RDI(tar rdi s=com2),
> I'm doing the eCos porting to our customize board based on
> Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging
> the ROM image which initialize the board. The problem is, for example,
> here is a sample instructions of the ROM image dump by gnu objdump:
> 00008060 <reset_vector>:
> 8060: e59f0458 ldr r0, [pc, #458]
> 8064: e5800000 str r0, [r0]
>
> 00008068 <warm_reset>:
> 8068: e3a00000 mov r0, #0 ; 0x0
> 806c: e5800040 str r0, [r0, #64]
> 8070: e59f144c ldr r1, [pc, #44c]
> 8074: e5912008 ldr r2, [r1, #8]
> 8078: e5802008 str r2, [r0, #8]
> 807c: e5912040 ldr r2, [r1, #64]
> 8080: e5802028 str r2, [r0, #40]
> 8084: ef000000 swi 0x00000000
>
> when I set a breakpoint"b *0x8070" then "continue", it breaks
> normally. But after that I type "stepi" to run next instruction.
> This message comes out and gdb was terminated:
>
> 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \
> STATUS_ACCESS_VIOLATION
> 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to
> arm-elf-gdb.exe.stack.dump
> Segmentation fault (core dump)
>
> This happens also when I set the 2nd breakpoint (for example, at 0x8080) and
> enter "continue". So I can only set one breakpoint at a time...
> Does any one have the same problem?
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From ac131313@cygnus.com Wed Jan 17 16:36:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: The ``obvious fix'' rule.
Date: Wed, 17 Jan 2001 16:36:00 -0000
Message-id: <3A663A02.5E0B397D@cygnus.com>
References: <3A64EDE9.74ADADAF@cygnus.com> <3A64F63A.9714D091@apple.com> <20010116204358.B10173@redhat.com>
X-SW-Source: 2001-01/msg00120.html
Content-length: 876
Christopher Faylor wrote:
>
> On Tue, Jan 16, 2001 at 05:32:42PM -0800, Stan Shebs wrote:
> >Perhaps a good mental test is "will the person who hates my work
> >the most be able to find fault with the change" - if so, then it's
> >not obvious and needs to be posted first. :-)
>
> I think that this is the best criteria for an "obvious fix" that
> I've ever heard.
You're meant to say the ``most obvious criteria'' ... :-)
A voting schema for issues was also suggested. At present we've got
what I'll refer to as a consensus approach. I think this is much better
than a so called vote and I think it better reflects how internet
discussion really operates. A discussion, assuming people can remain
focused, normally reaches the point where, appreciates understands the
decision. A voting system, by its nature, typically alienates 49.9999%
of the population.
Andrew
From tromey@redhat.com Wed Jan 17 17:46:00 2001
From: Tom Tromey <tromey@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb test results web page
Date: Wed, 17 Jan 2001 17:46:00 -0000
Message-id: <87ae8psjei.fsf@creche.redhat.com>
References: <200101172246.OAA07607@bosch.cygnus.com>
X-SW-Source: 2001-01/msg00121.html
Content-length: 886
>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
Michael> It appears that the results page counts only results that
Michael> start in column 1. That's fine for "gdb.sum" files, but it
Michael> misses 90% of the results in "gdb.log" files. It looks like
Michael> every entry in the current database suffers from this
Michael> problem.
Hmm. One approach would be to fix dejagnu so that pass/fail
indications always start on a new line. At least, this doesn't seem
unreasonable to me.
Michael> The upload page should say more clearly whether it wants a
Michael> "gdb.log" file or a "gdb.sum" file. And if it does not
Michael> handle both types, then it needs to reject files of the wrong
Michael> type.
It wants .log files.
Michael> I have a lot more opinions but I better shut up before I get
Michael> recruited!
Indeed.
Tom
From ac131313@cygnus.com Wed Jan 17 17:47:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Pulling in purging of deprecated code?
Date: Wed, 17 Jan 2001 17:47:00 -0000
Message-id: <3A664AAC.FAC65760@cygnus.com>
References: <393723F4.48AA76AA@cygnus.com>
X-SW-Source: 2001-01/msg00122.html
Content-length: 719
Andrew Cagney wrote:
>
> Hello,
>
> With the 4.18 release, gdb started identifying obsolete code that was
> going to be deleted. The 5.0 release saw the first of that code
> removed.
>
> I'd like to suggest a slight acceleration of the process. As soon as
> (or slightly after) a release has gone out the obsolete code be removed.
>
> This would remove the overlap that currently exists (hosts/targets may
> be obsolete from the previous or next release) and also reduce the
> amount of bagage GDB carries.
>
> Since the repository is public (and downloadable) the full history is
> accessable.
To close this. I got one response (agreeing with the proposal) so I'll
shortly be following this through.
Andrew
From tromey@redhat.com Wed Jan 17 18:01:00 2001
From: Tom Tromey <tromey@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb test results web page
Date: Wed, 17 Jan 2001 18:01:00 -0000
Message-id: <8766jdsj8j.fsf@creche.redhat.com>
References: <200101172246.OAA07607@bosch.cygnus.com>
X-SW-Source: 2001-01/msg00123.html
Content-length: 401
>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
Michael> The upload page should say more clearly whether it wants a
Michael> "gdb.log" file or a "gdb.sum" file. And if it does not
Michael> handle both types, then it needs to reject files of the wrong
Michael> type.
Can you suggest how to do this? I don't see a way to tell the two
kinds of files apart.
Tom
From ac131313@cygnus.com Wed Jan 17 18:07:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: gdb test results web page
Date: Wed, 17 Jan 2001 18:07:00 -0000
Message-id: <3A664F5E.B67906BB@cygnus.com>
References: <20010117165403.A15748@redhat.com>
X-SW-Source: 2001-01/msg00124.html
Content-length: 1201
A quick thanks, I'll update the web pages.
Also a follow-up. This was an unofficial item on the GDB 5.1 release
criteria. There had been a number of requests for a mechanism that
allowed people to publish test results - this is it.
When it comes to 5.1 it should be possible to just look at the test
results pages and provided they are ok things can be released. (well
sounds good in theory :-)
Andrew
Christopher Faylor wrote:
>
> I've been meaning to announce the existence of the gdb test results web
> page for some time. It is here:
>
> http://sources.redhat.com/cgi-bin/gdb.cgi
>
> This web page uses some cool software, written by Tom Tromey that helps
> in the categorization and comparison of test results. You can upload
> your own test results here by clicking on the "upload a testsuite log
> file" link or by sending email to gdb-testresults@sources.redhat.com.
>
> We're thinking of setting up a project on sources.redhat.com devoted to
> the "Terf" software which handles this web page so that people can
> improve it. If anyone is interested in joining this project let me
> know. You'll need to be fairly proficient in perl, since Terf is written
> in perl.
>
> cgf
From chastain@cygnus.com Wed Jan 17 20:18:00 2001
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: tromey@redhat.com
Cc: gdb@sources.redhat.com
Subject: Re: gdb test results web page
Date: Wed, 17 Jan 2001 20:18:00 -0000
Message-id: <200101180421.UAA13606@train2.cygnus.com>
X-SW-Source: 2001-01/msg00125.html
Content-length: 1362
Tom Tromey writes:
Tom> Can you suggest how to do this? I don't see a way to tell the two
Tom> kinds of files apart.
Here are some differences to key on for gdb.sum versus gdb.log:
A gdb.log file has several '^Using' lines in the first few lines.
A gdb.log file ends with the line '^runtest completed ...'
You could also parse the '^# of ...' totals near the end of the file,
and compare them with the count you get by grepping. If the counts do
not match you could reject the file. That would protect against lots of
kinds of user errors, script shortcomings, and bogus input files.
Tom> Hmm. One approach would be to fix dejagnu so that pass/fail
Tom> indications always start on a new line. At least, this doesn't seem
Tom> unreasonable to me.
Ouch, an interface problem. You are suggesting we change this:
Program exited with code 01.^M
(gdb) PASS: gdb.base/a2-run.exp: run "run" with no args
To this:
Program exited with code 01.^M
(gdb)
PASS: gdb.base/a2-run.exp: run "run" with no args
I have two concerns. First, if we make this change in Dejagnu, it affects
all tools tested with Dejagnu. And second, it means that nobody can enter
any test results until this change gets made and propagated in Dejagnu.
So I'm more inclined to say: leave the sender [dejagnu] alone, and change
the receiver to be more liberal.
Michael
From ac131313@cygnus.com Wed Jan 17 20:24:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Obsolete systems for GDB 5.1?
Date: Wed, 17 Jan 2001 20:24:00 -0000
Message-id: <3A666F6F.90372D25@cygnus.com>
X-SW-Source: 2001-01/msg00126.html
Content-length: 1350
I'd like to table the following as candidates for removal from GDB.
They would be marked as obsolete in GDB 5.1.
The following systems were identified because they continue to use the
*xdep.c* file.
Rather than fix these platforms, I'd like to remove them. Eliminating
*xdep.c from GDB should greatly simplify things like the move to
automake (and more immediatly the long outstanding need to fix
gdb/gdbserv's configury).
m68030-sony-*) gdb_host=news1000 ;;
m68*-isi-*) gdb_host=isi ;;
m68*-sony-*) gdb_host=news ;;
a29k-*-*) gdb_host=ultra3 ;;
ns32k-umax-*) gdb_host=umax ;;
mpw*-*-*) see mpw-config.in
The following systems were identified because they they do not have a
maintainer and are known to not build:
i[3456]86-*-sunos*) gdb_host=sun386 ;; (This is *NOT* solaris-2)
ns32k-umax-*) gdb_host=umax ;;
Uses deleted function safe_strsignal().
The following systems were identified because their target does not have
a maintainer *AND* I was not able to build them (FreeBSD host). The
file gdb/MAINTAINERS will contain up-to-date status on this and other
targets.
i960
mcore
mn10200
ns32k
ns32k-*-mach3*) gdb_host=ns32km3 ;;
ns32k-*-netbsd*) gdb_host=nbsd ;;
ns32k-umax-*) gdb_host=umax ;;
ns32k-utek-sysv*) gdb_host=merlin ;;
tic80
v850
w65
z8k
Comments. Suggestions and rejections.
Andrew
From cgf@redhat.com Wed Jan 17 20:28:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: Obsolete systems for GDB 5.1?
Date: Wed, 17 Jan 2001 20:28:00 -0000
Message-id: <20010117232813.A16700@redhat.com>
References: <3A666F6F.90372D25@cygnus.com>
X-SW-Source: 2001-01/msg00127.html
Content-length: 1517
FWIW, I think that the removal of all of these makes sense.
cgf
On Thu, Jan 18, 2001 at 03:22:07PM +1100, Andrew Cagney wrote:
>I'd like to table the following as candidates for removal from GDB.
>They would be marked as obsolete in GDB 5.1.
>
>
>The following systems were identified because they continue to use the
>*xdep.c* file.
>
>Rather than fix these platforms, I'd like to remove them. Eliminating
>*xdep.c from GDB should greatly simplify things like the move to
>automake (and more immediatly the long outstanding need to fix
>gdb/gdbserv's configury).
>
> m68030-sony-*) gdb_host=news1000 ;;
> m68*-isi-*) gdb_host=isi ;;
> m68*-sony-*) gdb_host=news ;;
> a29k-*-*) gdb_host=ultra3 ;;
> ns32k-umax-*) gdb_host=umax ;;
> mpw*-*-*) see mpw-config.in
>
>
>The following systems were identified because they they do not have a
>maintainer and are known to not build:
>
> i[3456]86-*-sunos*) gdb_host=sun386 ;; (This is *NOT* solaris-2)
> ns32k-umax-*) gdb_host=umax ;;
> Uses deleted function safe_strsignal().
>
>
>The following systems were identified because their target does not have
>a maintainer *AND* I was not able to build them (FreeBSD host). The
>file gdb/MAINTAINERS will contain up-to-date status on this and other
>targets.
>
> i960
> mcore
> mn10200
> ns32k
> ns32k-*-mach3*) gdb_host=ns32km3 ;;
> ns32k-*-netbsd*) gdb_host=nbsd ;;
> ns32k-umax-*) gdb_host=umax ;;
> ns32k-utek-sysv*) gdb_host=merlin ;;
> tic80
> v850
> w65
> z8k
>
>Comments. Suggestions and rejections.
From ac131313@cygnus.com Wed Jan 17 20:54:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: [rfc] Remove 5.0 obsolete code
Date: Wed, 17 Jan 2001 20:54:00 -0000
Message-id: <3A66767C.35FC7DC9@cygnus.com>
X-SW-Source: 2001-01/msg00128.html
Content-length: 8299
Hello,
This follows up a discussion on the gdb@ mailing list. It removes the
obsolete targets. I would draw your attention to the news file where it
will now read:
* OBSOLETE configurations
....
Configurations that have been declared obsolete in this release have
been commented out. Unless there is activity to revive these
configurations, the next release of GDB will have their sources
permanently REMOVED.
In GDB 5.0 this note read:
Configurations that have been declared obsolete will be commented out,
but the code will be left in place. If there is no activity to revive
these configurations before the next release of GDB, the sources will
be permanently REMOVED.
The old paragraph could give the impression that the removal would only
occure just before the next GDB release. Given that everything is in
CVS this is no longer needed.
Andrew
Thu Jan 18 14:03:13 2001 Andrew Cagney <cagney@b1.cygnus.com>
* configure.tgt: Remove references to convex, pyramid, altos and
tahoe.
* configure.host: Ditto.
* MAINTAINERS: Ditto.
* NEWS: Update.
* tahoe-tdep.c: Delete obsolete file.
* pyr-xdep.c: Ditto.
* pyr-tdep.c: Ditto.
* convex-tdep.c: Ditto.
* convex-xdep.c: Ditto.
* config/tahoe/xm-tahoe.h: Ditto.
* config/tahoe/tm-tahoe.h: Ditto.
* config/tahoe/tahoe.mt: Ditto.
* config/tahoe/tahoe.mh: Ditto.
* config/pyr/xm-pyr.h: Ditto.
* config/pyr/tm-pyr.h: Ditto.
* config/pyr/pyramid.mt: Ditto.
* config/pyr/pyramid.mh: Ditto.
* config/m68k/xm-altos.h: Ditto.
* config/m68k/tm-altos.h: Ditto.
* config/m68k/altos.mt: Ditto.
* config/m68k/altos.mh: Ditto.
* config/convex/xm-convex.h: Ditto.
* config/convex/tm-convex.h: Ditto.
* config/convex/convex.mt: Ditto.
* config/convex/convex.mh: Ditto.
* config/convex/Convex.notes: Ditto.
* config/arm/xm-arm.h: Ditto.
* config/arm/nm-arm.h: Ditto.
* config/arm/arm.mt: Ditto.
* config/arm/arm.mh: Ditto.
* arm-convert.s: Ditto.
* arm-xdep.c: Ditto.
* altos-xdep.c: Ditto.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.62
diff -p -r1.62 MAINTAINERS
*** MAINTAINERS 2001/01/16 22:45:48 1.62
--- MAINTAINERS 2001/01/18 03:36:42
*************** maintainer works with the native maintai
*** 42,49 ****
Jim Ingham jingham@apple.com
Scott Bambrough scottb@netwinder.org
- convex OBSOLETE
-
d10v Andrew Cagney cagney@cygnus.com
d30v David Taylor taylor@cygnus.com
--- 42,47 ----
*************** maintainer works with the native maintai
*** 80,87 ****
powerpc Kevin Buettner kevinb@cygnus.com
Nick Duffek nsd@cygnus.com
- pyramid OBSOLETE
-
romp maintenance only (?)
rs6000 (see rs6000 native and ppc target)
--- 78,83 ----
*************** maintainer works with the native maintai
*** 89,96 ****
sh Elena Zannoni ezannoni@cygnus.com
sparc David Taylor taylor@cygnus.com
-
- tahoe OBSOLETE
tic80 maintenance only (tic80-coff)
v850 maintenance only (v850-elf)
--- 85,90 ----
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.11
diff -p -r1.11 NEWS
*** NEWS 2000/10/24 05:22:11 1.11
--- NEWS 2001/01/18 03:37:26
*************** x86 FreeBSD 3.x and 4.x i[3456]86*-fr
*** 14,20 ****
x86 FreeBSD before 2.2 i[3456]86*-freebsd{1,2.[01]}*,
! * Deleted configurations
* Other news:
--- 14,31 ----
x86 FreeBSD before 2.2 i[3456]86*-freebsd{1,2.[01]}*,
! Configurations that have been declared obsolete in this release have
! been commented out. Unless there is activity to revive these
! configurations, the next release of GDB will have their sources
! permanently REMOVED.
!
! * REMOVED configurations
!
! Altos 3068 m68*-altos-*
! Convex c1-*-*, c2-*-*
! Pyramid pyramid-*-*
! ARM RISCix arm-*-* (as host)
! Tahoe tahoe-*-*
* Other news:
Index: configure.host
===================================================================
RCS file: /cvs/src/src/gdb/configure.host,v
retrieving revision 1.10
diff -p -r1.10 configure.host
*** configure.host 2000/11/26 20:04:41 1.10
--- configure.host 2001/01/18 03:37:26
*************** case "${host_cpu}" in
*** 12,23 ****
alpha*) gdb_host_cpu=alpha ;;
arm*) gdb_host_cpu=arm ;;
- # OBSOLETE c[12]) gdb_host_cpu=convex ;;
hppa*) gdb_host_cpu=pa ;;
i[3456]86*) gdb_host_cpu=i386 ;;
m68*) gdb_host_cpu=m68k ;;
m88*) gdb_host_cpu=m88k ;;
- # OBSOLETE pyramid) gdb_host_cpu=pyr ;;
powerpc*) gdb_host_cpu=powerpc ;;
sparc64) gdb_host_cpu=sparc ;;
*) gdb_host_cpu=$host_cpu ;;
--- 12,21 ----
*************** alpha*-*-freebsd*) gdb_host=fbsd ;;
*** 39,46 ****
arm*-*-linux*) gdb_host=linux ;;
arm*-*-*) gdb_host=arm ;;
- # OBSOLETE c[12]-*-*) gdb_host=convex ;;
-
hppa*-*-bsd*) gdb_host=hppabsd ;;
hppa*-*-hiux*) gdb_host=hppahpux ;;
hppa*-*-hpux10.20) gdb_host=hpux1020 ;;
--- 37,42 ----
*************** m680[01]0-sun-sunos3*) gdb_host=sun2os3
*** 90,96 ****
m680[01]0-sun-sunos4*) gdb_host=sun2os4 ;;
m68030-sony-*) gdb_host=news1000 ;;
- # OBSOLETE m68*-altos-*) gdb_host=altos ;;
m68*-apollo*-sysv*) gdb_host=apollo68v ;;
m68*-apollo*-bsd*) gdb_host=apollo68b ;;
m68*-att-*) gdb_host=3b1 ;;
--- 86,91 ----
*************** powerpcle-*-solaris*) gdb_host=solaris ;
*** 140,149 ****
powerpc-*-linux*) gdb_host=linux ;;
powerpc-*-netbsd*) gdb_host=nbsd ;;
- # OBSOLETE pn-*-*) gdb_host=pn ;;
-
- # OBSOLETE pyramid-*-*) gdb_host=pyramid ;;
-
romp-*-*) gdb_host=rtbsd ;;
rs6000-*-lynxos*) gdb_host=rs6000lynx ;;
--- 135,140 ----
*************** sparc64-*-*) gdb_host=sun4sol2 ;;
*** 163,170 ****
strongarm-*-*) gdb_host=arm ;;
xscale-*-*) gdb_host=arm ;;
-
- # OBSOLETE tahoe-*-*) gdb_host=tahoe ;;
vax-*-bsd*) gdb_host=vaxbsd ;;
vax-*-ultrix2*) gdb_host=vaxult2 ;;
--- 154,159 ----
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.16
diff -p -r1.16 configure.tgt
*** configure.tgt 2000/12/14 20:15:45 1.16
--- configure.tgt 2001/01/18 03:37:26
*************** case "${target_cpu}" in
*** 14,20 ****
alpha*) gdb_target_cpu=alpha ;;
arm*) gdb_target_cpu=arm ;;
- # OBSOLETE c[12]) gdb_target_cpu=convex ;;
hppa*) gdb_target_cpu=pa ;;
i[3456]86*) gdb_target_cpu=i386 ;;
m68hc11*|m6811*) gdb_target_cpu=m68hc11 ;;
--- 14,19 ----
*************** m68*) gdb_target_cpu=m68k ;;
*** 22,28 ****
m88*) gdb_target_cpu=m88k ;;
mips*) gdb_target_cpu=mips ;;
powerpc*) gdb_target_cpu=powerpc ;;
- # OBSOLETE pyramid) gdb_target_cpu=pyr ;;
sparc*) gdb_target_cpu=sparc ;;
thumb*) gdb_target_cpu=arm ;;
strongarm*) gdb_target_cpu=arm ;;
--- 21,26 ----
*************** arm*-*-* | thumb*-*-* | strongarm*-*-*)
*** 63,70 ****
xscale-*-*) gdb_target=embed
configdirs="$configdirs rdi-share"
;;
- # OBSOLETE c1-*-*) gdb_target=convex ;;
- # OBSOLETE c2-*-*) gdb_target=convex ;;
d10v-*-*) gdb_target=d10v ;;
d30v-*-*) gdb_target=d30v ;;
--- 61,66 ----
*************** m68*-apollo*-bsd*) gdb_target=apollo68b
*** 149,155 ****
m68*-bull-sysv*) gdb_target=dpx2 ;;
m68*-hp-bsd*) gdb_target=hp300bsd ;;
m68*-hp-hpux*) gdb_target=hp300hpux ;;
- # OBSOLETE m68*-altos-*) gdb_target=altos ;;
m68*-att-*) gdb_target=3b1 ;;
m68*-cisco*-*) gdb_target=cisco ;;
m68*-ericsson-*) gdb_target=es1800 ;;
--- 145,150 ----
*************** powerpcle-*-eabi* | powerpcle-*-sysv* |
*** 255,262 ****
powerpc-*-linux*) gdb_target=linux ;;
powerpc-*-vxworks*) gdb_target=vxworks ;;
- # OBSOLETE pyramid-*-*) gdb_target=pyramid ;;
-
rs6000-*-lynxos*) gdb_target=rs6000lynx
configdirs="${configdirs} gdbserver" ;;
rs6000-*-aix4*) gdb_target=aix4 ;;
--- 250,255 ----
*************** sparc86x-*-*) gdb_target=sparclite ;;
*** 288,295 ****
# deleted though presumably it should be eventually.
#sparc64-*-solaris2*) gdb_target=sp64sol2 ;;
sparc64-*-*) gdb_target=sp64 ;;
-
- # OBSOLETE tahoe-*-*) gdb_target=tahoe ;;
tic80-*-*) gdb_target=tic80
configdirs="${configdirs} gdbserver" ;;
--- 281,286 ----
From ac131313@cygnus.com Thu Jan 18 06:43:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Will Cohen <wcohen@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Handling of mips disassembly by gdb
Date: Thu, 18 Jan 2001 06:43:00 -0000
Message-id: <3A67009D.4AEBD43B@cygnus.com>
References: <39F0C5E9.CC6A0CF9@redhat.com>
X-SW-Source: 2001-01/msg00129.html
Content-length: 970
Will Cohen wrote:
>
> The disassembly performed by the function _print_insn_mips in
> opcode/mips-dis.c is dependent on the mach field of the struct info
> passed to the function. Unfortunately the mach field is alway set to
> zero because TM_PRINT_INSN_MACH is defined to be 0 in
> gdb/config/mips/tm-mip.h. Is there a reason that this must be set to
> zero? Wouldn't it be more appropriate to set it to
> ((TARGET_PRINT_INSN_INFO)->mach)? Changing this line allows the
> disassembler to generate model specific instructions.
>
> Should I generate a patch to fix this and submit it to binutils? Or is
> there a reason this define was set to zero?
You may want to check exactly how objdump handles things like MIPS16 vs
MIPS-1-IV code and ARM vs THUMB. By default, GDB just calls the
dissassembler and hopes that it knows what the architecture is for the
current memory range.
For your case, does a simple objdump dissassemble code the way you
expect?
Andrew
From tromey@redhat.com Thu Jan 18 13:40:00 2001
From: Tom Tromey <tromey@redhat.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: gdb test results web page
Date: Thu, 18 Jan 2001 13:40:00 -0000
Message-id: <87g0igpv17.fsf@creche.redhat.com>
References: <200101180421.UAA13606@train2.cygnus.com>
X-SW-Source: 2001-01/msg00130.html
Content-length: 901
>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
Michael> I have two concerns. First, if we make this change in
Michael> Dejagnu, it affects all tools tested with Dejagnu. And
Michael> second, it means that nobody can enter any test results until
Michael> this change gets made and propagated in Dejagnu.
I think the current behavior is just a dejagnu bug. I doubt anybody
relies on "PASS" or "FAIL" not appearing at the start of a line. And
I doubt it was ever intended to work the way it does -- dejagnu wasn't
that carefully built.
Second, I don't think propagation is a big problem. I thought
everybody was supposed to use the dejagnu in the src repository.
If we were dealing with non-free software I would agree with you. But
I think with free software we can afford to have a higher standard --
fix the bug where it lies, not work around it elsewhere.
Tom
From jtc@redback.com Thu Jan 18 13:53:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Obsolete systems for GDB 5.1?
Date: Thu, 18 Jan 2001 13:53:00 -0000
Message-id: <5mwvbs4ruu.fsf@jtc.redback.com>
References: <3A666F6F.90372D25@cygnus.com>
X-SW-Source: 2001-01/msg00131.html
Content-length: 804
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I'd like to table the following as candidates for removal from
Andrew> GDB. They would be marked as obsolete in GDB 5.1. The
Andrew> following systems were identified because their target does
Andrew> not have a maintainer *AND* I was not able to build them
Andrew> (FreeBSD host). The file gdb/MAINTAINERS will contain
Andrew> up-to-date status on this and other targets.
Andrew>
Andrew> ns32k
Andrew> ns32k-*-mach3*) gdb_host=ns32km3 ;;
Andrew> ns32k-*-netbsd*) gdb_host=nbsd ;;
Andrew> ns32k-umax-*) gdb_host=umax ;;
Andrew> ns32k-utek-sysv*) gdb_host=merlin ;;
Andrew>
Andrew> Comments. Suggestions and rejections.
I'll be fixing the ns32k-*-netbsd* before 5.1.
--jtc
--
J.T. Conklin
RedBack Networks
From chienyul@yahoo.com Thu Jan 18 14:18:00 2001
From: Jeremy Lin <chienyul@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Using gdb with JEENI
Date: Thu, 18 Jan 2001 14:18:00 -0000
Message-id: <20010118181844.15687.qmail@web2302.mail.yahoo.com>
X-SW-Source: 2001-01/msg00132.html
Content-length: 2327
It is cygwin 1.1, I installed in in August 2000.
Thanks!
Jeremy Lin
--- Fernando Nasser <fnasser@cygnus.com> wrote:
> Which version of Cygwin are you using?
>
> Jeremy Lin wrote:
> >
> > I have a problem using JEENI with GDB 5.0 debugging.
> > JEENI FirmwareVersion:2.0
> > Connected via serial port and RDI(tar rdi s=com2),
> > I'm doing the eCos porting to our customize board based on
> > Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging
> > the ROM image which initialize the board. The problem is, for example,
> > here is a sample instructions of the ROM image dump by gnu objdump:
> > 00008060 <reset_vector>:
> > 8060: e59f0458 ldr r0, [pc, #458]
> > 8064: e5800000 str r0, [r0]
> >
> > 00008068 <warm_reset>:
> > 8068: e3a00000 mov r0, #0 ; 0x0
> > 806c: e5800040 str r0, [r0, #64]
> > 8070: e59f144c ldr r1, [pc, #44c]
> > 8074: e5912008 ldr r2, [r1, #8]
> > 8078: e5802008 str r2, [r0, #8]
> > 807c: e5912040 ldr r2, [r1, #64]
> > 8080: e5802028 str r2, [r0, #40]
> > 8084: ef000000 swi 0x00000000
> >
> > when I set a breakpoint"b *0x8070" then "continue", it breaks
> > normally. But after that I type "stepi" to run next instruction.
> > This message comes out and gdb was terminated:
> >
> > 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \
> > STATUS_ACCESS_VIOLATION
> > 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to
> > arm-elf-gdb.exe.stack.dump
> > Segmentation fault (core dump)
> >
> > This happens also when I set the 2nd breakpoint (for example, at 0x8080)
> and
> > enter "continue". So I can only set one breakpoint at a time...
> > Does any one have the same problem?
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
>
> --
> Fernando Nasser
> Red Hat - Toronto E-Mail: fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario M4P 2C9
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
From cgf@redhat.com Thu Jan 18 14:36:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: gdb test results web page
Date: Thu, 18 Jan 2001 14:36:00 -0000
Message-id: <20010118173615.A1274@redhat.com>
References: <200101180421.UAA13606@train2.cygnus.com> <87g0igpv17.fsf@creche.redhat.com>
X-SW-Source: 2001-01/msg00133.html
Content-length: 873
On Thu, Jan 18, 2001 at 11:36:20AM -0700, Tom Tromey wrote:
>>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
>
>Michael> I have two concerns. First, if we make this change in
>Michael> Dejagnu, it affects all tools tested with Dejagnu. And
>Michael> second, it means that nobody can enter any test results until
>Michael> this change gets made and propagated in Dejagnu.
>
>I think the current behavior is just a dejagnu bug. I doubt anybody
>relies on "PASS" or "FAIL" not appearing at the start of a line. And
>I doubt it was ever intended to work the way it does -- dejagnu wasn't
>that carefully built.
It is not that hard to modify terf to find the PASS/FAIL/XFAIL in other
places than at the beginning of the line. I've just checked in a change
to do this.
Do you think this is a bad idea, Tom? If so, I'll revert the change.
cgf
From jlarmour@redhat.com Thu Jan 18 14:40:00 2001
From: jlarmour@redhat.com (Jonathan Larmour)
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: Obsolete systems for GDB 5.1?
Date: Thu, 18 Jan 2001 14:40:00 -0000
Message-id: <200101181826.f0IIQZs16097@murgh.cambridge.redhat.com>
References: <3A666F6F.90372D25@cygnus.com>
X-SW-Source: 2001-01/msg00135.html
Content-length: 567
In article < 3A666F6F.90372D25@cygnus.com > you write:
>I'd like to table the following as candidates for removal from GDB.
>They would be marked as obsolete in GDB 5.1.
[snip]
> v850
It may not build right now, but we support this within Red Hat. Just
because there is no individual capable of being the maintainer
doesn't mean that no-one will be fixing it: the entity known as
Red Hat as a whole will.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine
From jtc@redback.com Thu Jan 18 14:40:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Obsolete systems for GDB 5.1?
Date: Thu, 18 Jan 2001 14:40:00 -0000
Message-id: <5mwvbs32nv.fsf@jtc.redback.com>
References: <3A666F6F.90372D25@cygnus.com>
X-SW-Source: 2001-01/msg00134.html
Content-length: 765
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> ns32k
Andrew> ns32k-*-mach3*) gdb_host=ns32km3 ;;
Andrew> ns32k-*-netbsd*) gdb_host=nbsd ;;
Andrew> ns32k-umax-*) gdb_host=umax ;;
Andrew> ns32k-utek-sysv*) gdb_host=merlin ;;
Andrew>
Andrew> Comments. Suggestions and rejections.
It seems that much of the ns32k build lossage was caused by a change
made to tm-umax.h between the 19990504 and 19990525 snapshots (I can
not narrow it down further, this was before the GDB repository on
sourceware was made the master repository, perhaps someone at cygnus
can track it down) where the FRAME_FIND_SAVED_REGS macro was removed.
There was no ChangeLog entry cooresponding to this change.
--jtc
--
J.T. Conklin
RedBack Networks
From tromey@redhat.com Thu Jan 18 15:16:00 2001
From: Tom Tromey <tromey@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb test results web page
Date: Thu, 18 Jan 2001 15:16:00 -0000
Message-id: <87lms8l9gb.fsf@creche.redhat.com>
References: <200101180421.UAA13606@train2.cygnus.com> <87g0igpv17.fsf@creche.redhat.com> <20010118173615.A1274@redhat.com>
X-SW-Source: 2001-01/msg00136.html
Content-length: 286
>>>>> "Chris" == Christopher Faylor <cgf@redhat.com> writes:
Chris> Do you think this is a bad idea, Tom? If so, I'll revert the
Chris> change.
I doubt it is actively bad.
I've just reached my limit of catering to dejagnu brokenness.
Perhaps I'll send a dejagnu patch.
Tom
From miocartu@hotmail.com Thu Jan 18 15:37:00 2001
From: "Bapsa" <miocartu@hotmail.com>
To: "gdb@sourceware.cygnus.com" <gdb@sourceware.cygnus.com>
Subject: Imprimi sin culpas!!
Date: Thu, 18 Jan 2001 15:37:00 -0000
Message-id: <08dc23236231211MAIL2@mail2.arnet.com.ar>
X-SW-Source: 2001-01/msg00137.html
Content-length: 859
Title: Untitled Document
ATENCION, NO TIRES TUS CARTUCHOS Â Â Â Â
Hola,
no queremos sacarte tu tiempo, si tenés cartuchos de
impresora, hace click en www.loscartuchos.com
o llamanos al 4828-0174 ,
los recuperamos en 24 horas y cuestan
$15 color o negro para cualquier impresora. No
importa donde vivas, tienen garantÃa, salen probados
y quedan como nuevos .
AHORA
AHORRAS, IMPRIMI SIN CULPAS
BAPSA
Â
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2001-01-17 13:04 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.31.0101171542280.22162-100000@www.cgsoftware.com>
2001-01-17 13:04 ` [aeb] Re: GNU toolchain and AEB Jens-Christian Lache
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox