This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: About using GDB with target ARM simulator


"Lim, Sung-taek" wrote:
> 
> First of all, thank you for your help.

 You are welcome...
 
> > "Lim, Sung-taek" wrote:
> > >
> > > I've built crossgcc for target arm-linux and gdb for target arm-elf. (couldn't match
> > > the two targets for some reasons but i thought it wouldn't matter. I couldn't find
> > > any difference between them. Is there any difference?)
> >
> >  The arm-elf is for embedded ARM with perhaps no opsys. Although the use for arm-linux
> > may be 'embedded', it really is a 'system' target...
> I know what you mean. Then what am I gonna do to know the details?

Downloading the ARM-ELF specification (as a PDF doc) via:      
http://www.arm.com/Documentation/ISTSpecs/

-------------------------------- clip ----------------------------------------------
This specification defines ARM Executable and Linking Format (ARM ELF). It follows the
structure of the Tool Interface Standards (TIS) Committee’s version 1.2 specification
of ELF (TIS-ELF). TIS-ELF is divided into three major sections that TIS-ELF calls books:

  o Book 1 defines generic, 32-bit ELF. All users of 32-bit ELF use the definitions
    given in book 1. Section 3 of this specification reproduces the content of book 1
    of TIS-ELF (Copyright Tool Interface Standards Committee 1995).

  o Book 2 defines processor specifics, the definitions used by all users of ELF for
    a given processor (in the case of TIS-ELF, for the Intel x86 architecture).
    Section 4 of this specification corresponds to book 2 of TIS-ELF and includes the
    ARM- and Thumb-specific definitions needed by all users of ARM ELF.

  o Book 3 defines operating system specifics. Section 5 of this specification corresponds
    to book 3 of TIS-ELF and includes ARM- and Thumb-specific definitions relating to the
    ARM Embedded Applications Binary Interface (ARM EABI). The ARM EABI underlies many
    ARM- and Thumb-based operating environments that follow the single address-space model.

Some operating systems—especially those founded on multiple virtual address spaces—define
their own conventions for using ARM ELF—especially in relation to shared objects and dynamic
linking. These OS-specific definitions build on sections 4 and 5 of this specification, but
replace section 5 of this specification with their own version of book 3 of TIS-ELF.
ARM LINUX does this, for example.
-------------------------------- clip ----------------------------------------------

 So the base for 'arm-elf' and 'arm-linux-gnu' may be the same, the 'static' parts, but the
extensions will differ... And recently a discussion about the GNU arm-elf not being compatible
with the ARM-debugger, ADW, SDT ?, was seen...

 Taking all the docs from the 'arm-linux' webpages (www.linux.org --> 'Projects'), will
give more info if the 'pure arm-elf' is the same in the 'arm-elf' and in 'arm-linux-gnu'...

> >  It is quite unclear (for me too) what is the board/monitor-environment the arm-simulator,
> > which is included with GDB, really simulates. But surely it isn't Linux/ARM.
>
> Do you mean that the difference between system environment makes gdb abnormally? Then
> probably I should look at the internals of gdb breakpoint mechanism and find the system-
> dependent part. Can anyone teach me already 'working' arm cross compilers and gdb set
> whatever detailed system they suppose?

 The simulator for arm-elf seems to simulate something called 'Demon'-monitor, or a 'armos'
opsys. The rest of GDB could work ok with static 'arm-linux-gnu' binaries. Only the 'syscalls'
implementations for the simulated opsys are wrong for 'arm-linux-gnu'...
 
> >  Building a "--host=i686-pc-linux-gnu --target=arm-linux-gnu" from the current GDB
> > snapshots could succeed. Expecting the target being supported in gdb-4.18.1 (almost
> > one year old) may be vain.
>
> I retried and succeeded to build gdb for target arm-linux but the problem is the same.

 For the 'i386-elf' I have the situation in the opposite direction. There is no simulator
for a 'generic i386-elf system', but there are systems like x86/Linux and SVR4 which can
run 'pure i386-elf' binaries, if linked against a 'glue library' which contains the low-
level I/O-functions (read(), write(), open(), lseek(),...) and the memory handling (sbrk(),...)
implemented for SVR4. So my 'i386-elf' C-library is in two parts. The 'libc.a' contains only
those functions which are target-independent, and the 'libsvr4.a' contains those glue
routines for interfacing to the SVR4 operating system layer. The 'libsvr4.a' can be replaced
with any other 'board support package', by just implementing the same functions for some
other system/hardware... So I can run the 'i386-elf' programs under SVR4/Linux-with-ibcs2,
or load them into a native SVR4/Linux GDB... The C-library is based on newlib, where this
kind of separation to 'pure' and 'glue' functions is natural...

 I cannot say how difficult it would be to separate the low-level-I/O and the memory handling
functions from glibc-2.1.2 or something, and replace them with interface functions to the arm-
simulator in GDB. Surely it can be possible, but the use of the system would be restricted to
only quick checks that the 'arm-linux-gnu' target compiler works somehow. Ok, then there would
be a 'libc.a' for pure 'arm-elf/linux' functions and a 'liblinux.a' for the ARM/Linux-syscalls
based I/O etc., and a 'libarmsim.a' for the same functions using the arm-simulator...
 
 Probably the 'arm-linux' pages have info about how to get the Linux-kernel running in a
target board, how to get the 'gdbserver' running over it and so on... The principles should
be just the same for 'ppc-linux-gnu', 'mips-linux-gnu', 'm68k-linux-gnu' and so on... So the
webpages for those 'other systems' may be useful too...

Questions like the following appear now and then in newsgroups and the answers can give more
info:

------------------- clip ------------------------------
On Thu, 6 Jan 2000 08:16:30 -0000, "John Funnell" <john@uphigh.freeserve.co.uk> wrote:

>Hi!
>I'm in the process of designing a 'network appliance' with an AMD Elan 586,
>100BaseT Ether, one DIMM and some Flash.  This is to run Linux at low power.
>Has anyone done anything like this before?  If so, can you help:
>*  How do you first bring up such a system with no BIOS, no floppy, no
>progarm in flash (it's probably soldered to the board), no CDROM and no IDE
>drives?
>*  What's the best Flash for this app, SMD, a Flash disk or something else
>and who makes them?
>*  What's the best way to run Linux in this enviroment?  Flash disk (does
>software exist)?  or RAM disk and occasional backup of persistent data to
>flash?
------------------- clip ------------------------------

This was from 'comp.sys.embedded'...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]