This is the mail archive of the
mailing list for the newlib project.
Newlib, GDB Simulators, and Configurations
- To: email@example.com, firstname.lastname@example.org
- Subject: Newlib, GDB Simulators, and Configurations
- From: Richard Black <email@example.com>
- Date: Fri, 03 Sep 99 14:20:07 +0100
- Cc: firstname.lastname@example.org
[ resending to sourceware addresses following bounce ]
This fall I am going to be teaching a computer architecture course using the
Arm processor. In the past I used the ARM LTD tools on Solaris, but the aging
bank of suns has finally been put out to pasture, so this year I am looking to
use the Arm simulator built into gdb.
There currently doesn't seem to exist any 'libc' like thing for programs which
are going to be run under gdb's simulator to link against (distributed with
gdb). It seems to be that using newlib would be the obvious candidate, and
I'll return to you any improvements that I make.
I have looked at the newlib distribution and it seems that I'd need to add
into libgloss/ the "os" stuff necessary for basic reading and writing through
the gdb simulator.
Currently libgloss/ doesn't support the Arm at all so I will have some config
hacking to do.
I'm wondering what this should be called. In this instance is gdb the hardware
or the operating system or both? What sort of config option should I be going
for. All the below have some merit, except the last one which is the only one
currently accepted by newlib (though even that is not accepted by libgloss).
Alternatively, should I be not specifying the 'coff' at all and getting the
newlib makefile to use the arm-unknown-coff cross-tools by some other method.
I've done some gnu development before, but never much config hacking never
mind inventing new config names.
Perhaps you have a standard naming scheme for this concept, or have some
advice (either about the config name or more generally).
[I am not currently on either gdb@ or newlib@ lists ]
Thanks in advance,