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] |
"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] |