From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8802 invoked by alias); 6 Jun 2006 20:49:33 -0000 Received: (qmail 8794 invoked by uid 22791); 6 Jun 2006 20:49:31 -0000 X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from sta-204-188-98-27.rockynet.com (HELO hermes.chez-thomas.org) (204.188.98.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Jun 2006 20:49:07 +0000 Received: by hermes.chez-thomas.org (Postfix, from userid 999) id 315E537C80E3; Tue, 6 Jun 2006 14:49:05 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on hermes.chez-thomas.org X-Spam-Level: Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id 744DA37C80D8; Tue, 6 Jun 2006 14:49:01 -0600 (MDT) Subject: Re: bug in RedBoot ELF loader? From: Gary Thomas To: Bert Thomas Cc: eCos development In-Reply-To: <4485F487.6080000@brothom.nl> References: <44857F82.1020302@brothom.nl> <448596BD.30304@arcom.com> <4485C3FA.30201@brothom.nl> <1149615229.15359.41.camel@hermes> <4485EE86.9040909@brothom.nl> <1149624902.15359.55.camel@hermes> <4485F487.6080000@brothom.nl> Content-Type: text/plain Organization: MLB Associates Date: Tue, 06 Jun 2006 20:49:00 -0000 Message-Id: <1149626938.15359.62.camel@hermes> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2006-06/txt/msg00012.txt.bz2 On Tue, 2006-06-06 at 22:32 +0100, Bert Thomas wrote: > > > > It means nonsense. > > > > I do not agree that it's common for programs to include their ELF > > header within the code. A *long* time ago, things were structured > > that way, but we've progressed quite a lot (since the 70's :-) > > Up until now I have been unable to find a program that, according to > readelf, does not include the headers. If you do readelf on something on > your system, do the program segment headers specify an offset that skips > the headers themselves? Of course - the headers are just that; descriptions of stuff to come _later_ in the file. A sane ELF file (files created by GNU ld behave this way) will have the various section headers first, followed by the actual program segments. There is no need for a loader (like RedBoot which is what started this discussion) to ever load the headers as part of the image, rather only process them to figure out what needs to be loaded and where. For example, a RAM program on my PowerPC system (suitable for loading with RedBoot) looks like this: [gthomas@hermes RAM]$ readelf -e install/bin/redboot.elf ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC Version: 0x1 Entry point address: 0x80100 Start of program headers: 52 (bytes into file) Start of section headers: 503664 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 40 (bytes) Number of section headers: 23 Section header string table index: 20 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .vectors PROGBITS 00080000 010000 001500 00 AX 0 0 256 [ 2] .text PROGBITS 00081500 011500 01be48 00 AX 0 0 4 [ 3] .fini PROGBITS 0009d348 034640 000000 00 W 0 0 1 [ 4] .rodata1 PROGBITS 0009d348 034640 000000 00 W 0 0 1 [ 5] .rodata PROGBITS 0009d348 02d348 0058f0 00 A 0 0 4 [ 6] .fixup PROGBITS 000a2c38 034640 000000 00 W 0 0 1 [ 7] .gcc_except_table PROGBITS 000a2c38 034640 000000 00 W 0 0 1 [ 8] .data PROGBITS 000a2c38 032c38 001a08 04 WAX 0 0 8 [ 9] .sbss NOBITS 000a4640 034640 0000a0 00 WA 0 0 4 [10] .bss NOBITS 000a46e0 034640 01db88 00 WA 0 0 32 [11] .debug_line PROGBITS 00000000 034640 00cf33 00 0 0 1 [12] .debug_info PROGBITS 00000000 041573 01fedb 00 0 0 1 [13] .debug_abbrev PROGBITS 00000000 06144e 007bc5 00 0 0 1 [14] .debug_aranges PROGBITS 00000000 069018 001a90 00 0 0 8 [15] .debug_pubnames PROGBITS 00000000 06aaa8 003323 00 0 0 1 [16] .debug_str PROGBITS 00000000 06ddcb 007688 01 MS 0 0 1 [17] .comment PROGBITS 00000000 075453 0005a0 00 0 0 1 [18] .debug_frame PROGBITS 00000000 0759f4 003cf4 00 0 0 4 [19] .debug_ranges PROGBITS 00000000 0796e8 0017a8 00 0 0 1 [20] .shstrtab STRTAB 00000000 07ae90 0000df 00 0 0 1 [21] .symtab SYMTAB 00000000 07b308 005e60 10 22 922 4 [22] .strtab STRTAB 00000000 081168 003e87 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x00080000 0x00080000 0x24640 0x42268 RWE 0x10000 Section to Segment mapping: Segment Sections... 00 .vectors .text .rodata .data .sbss .bss All of the program and section headers are in the first 0x10000 bytes of the file (actually much less than that). The real data, which is all that RedBoot needs to load into RAM starts at offset 0x10000 in the file. > > If my analysis is wrong, can you explain what's wrong? > > Do linker scripts have an influence on this? (I mean: other then > obviously the number and size of segments) > > Bert -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------