Re: [avr-gcc-list] avr-objcopy not copying custom section...
SHF_WRITE This section contains data that should be writable during process execution. SHF_ALLOC This section occupies memory during process execution. Some con‐ trol sections do not reside in the memory image of an object file. This attribute is off for those sections. SHF_EXECINSTR This section contains executable machine instructions. SHF_MASKPROC All bits included in this mask are reserved for processor-spe‐ cific semantics. So we can see that the ELF format does provide explicit flags for X and A. Yes, ELF does provide X and A. I don't disagree. And Yes, they directly map to 'CODE' and 'ALLOC' flags printed by objdump. Sections: Idx Name Size VMA LMA File off Algn 0 .text 00ca 0094 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .bss 0002 00800100 00800100 015e 2**0 ALLOC But the flags that ELF does not specify are - 'CONTENTS' and 'LOAD'. These are BFD specific flags. Objdump program computes and prints them in section headers regardless of the object file format type (mostly). So, even if we are dumping ELF sections, objdump prints certain flags which are not directly specified by ELF. This is the point I am referring to. Hopefully I am clear. Anitha ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objcopy not copying custom section...
On 25.05.11 18:55, Boyapati, Anitha wrote: On 26.02.11 20:22, Boyapati, Anitha wrote: Actually, looking back, I don’t get the meaning of this. Erik wrote: Having just now seen this post, I'll offer the following thoughts. ... How can a section be ‘executable’ without being ‘allocatable’ in ELF? An overlay would fit that case. Ok! This is interesting. Perhaps the question relates instead to the ELF format's ability to distinguish the cases. OK, the p_flags member of the Phdr struct only provides for X, W, and R in its bitmask, according to the elf manpage, so the question seems fair. Yes. That is where the confusion stemmed from. Hi Anitha, Last time, I didn't look exhaustively for flags in the ELF format. With the aid of readelf -e test.elf, we can see that there are more section flags in the section header: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 94 3a 00 AX 0 0 1 [ 2] .data PROGBITS00800100 ce 00 00 WA 0 0 1 [ 3] .bss NOBITS 00800100 ce 00 00 WA 0 0 1 [ 4] .noinit PROGBITS00800100 ce 00 00 W 0 0 1 [ 5] .eeprom PROGBITS0081 ce 00 00 W 0 0 1 [ 6] .shstrtab STRTAB ce 3c 00 0 0 1 [ 7] .symtab SYMTAB 000274 0002a0 10 8 28 4 [ 8] .strtab STRTAB 000514 000146 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) I overlooked that before. In the sh_flags member of the Shdr struct, the ELF format does have separate explicit alloc and execute flags. ... 'objdump' program works on BFD structures. The set of BFD section flags for a super set to ELF section flags. So, the dump of section headers shows BFD flags but not ELF flags. But it is an ELF file that we are dumping, so any explicit flags we read must be in the ELF format. I just forgot about section headers, and didn't look for sh_flags, and that's where the missing flags reside, AIUI. ... The only mystery seems to be whether any of these flags used earlier in the toolchain become implicit in the ELF file, but that's just an implementation detail. I agree that there is an independence of attributes to certain extent. But this information pushed my curiosity further on how attributes are calculated for user-defined sections. I dug a little more. Binutils seems to work out the permutations and combinations of them. For e.g, as you pointed out .eeprom has CONTENTS but is not 'ALLOC'. Obviously, this involves lot of implementation detail that possibly considers 'size' of the section to make it ALLOC. Since the size is 0, the .eeprom section is not ALLOC. (Making it CONTENTS is a little but may be that is default. I am sorry but this is just my wild guess, I could be wrong.) Yes, ALLOC could in practical terms be implict, I agree, but the SHF_ALLOC bit in sh_flags makes it explicit in ELF, we now see. ... I find this useful. http://ftp.gnu.org/pub/old-gnu/Manuals/bfd-2.9.1/html_node/bfd_13.html Thanks for the link. I've had a look around, and will read more on return from a week on the family farm. (From tomorrow. Tools will be chainsaw and bulldozer, not gnu tools.) Thanks for sharing your thoughts on overlays. You are most welcome. After more than a quarter of a century of embedded development, it is more interesting to explore odd corners of the toolchain than it is to do yet more code development. (Though I still enjoy tweaking linker scripts for odd cases.) Erik -- We've found that people are signing contracts and a couple of years down the road looking back and thinking the equity in my home is being eaten away severely and obviously it is because of the compounding interest, she added. [Describing Reverse Mortgages] - http://abc.com.au/news/stories/2011/05/25/3226833.htm ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objcopy not copying custom section...
On 26.02.11 20:22, Boyapati, Anitha wrote: ➢ asm( .section .version,\x\\n Actually, looking back, I don’t get the meaning of this. Having just now seen this post, I'll offer the following thoughts. The flags provide independent control of section attributes. If I have a separate mechanism for loading a special section (an overlay for example) then it is useful to have one or more executable sections which are not initially loaded, with only one of them being allocated space. That may be more useful on targets other than the AVR. On the AVR we do have .eeprom, which has CONTENTS, but is not ALLOC. (OK, it's not executable, but demonstrates the independence of the attributes.) How can a section be ‘executable’ without being ‘allocatable’ in ELF? An overlay would fit that case. Ok! This is interesting. Perhaps the question relates instead to the ELF format's ability to distinguish the cases. OK, the p_flags member of the Phdr struct only provides for X, W, and R in its bitmask, according to the elf manpage, so the question seems fair. Yes. That is where the confusion stemmed from. $ avr-objdump -h test.elf test.elf: file format elf32-avr Sections: Idx Name Size VMA LMA File off Algn 0 .text 003a 0094 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00800100 003a 00ce 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00800100 003a 00ce 2**0 ALLOC 3 .noinit 00800100 00800100 00ce 2**0 CONTENTS 4 .eeprom 0081 0081 00ce 2**0 CONTENTS Voila, even if some of the flags listed, i.e. CONTENTS, ALLOC, LOAD, don't have an obvious explicit presence in the Phdr, they are nevertheless accurate. 'objdump' program works on BFD structures. The set of BFD section flags for a super set to ELF section flags. So, the dump of section headers shows BFD flags but not ELF flags. A quick glance is as far as my current curiosity extends, but it's clear that the flags are supported by the tools, even if the details of utilisation of the ELF file format aren't immediately obvious. The only mystery seems to be whether any of these flags used earlier in the toolchain become implicit in the ELF file, but that's just an implementation detail. I agree that there is an independence of attributes to certain extent. But this information pushed my curiosity further on how attributes are calculated for user-defined sections. I dug a little more. Binutils seems to work out the permutations and combinations of them. For e.g, as you pointed out .eeprom has CONTENTS but is not 'ALLOC'. Obviously, this involves lot of implementation detail that possibly considers 'size' of the section to make it ALLOC. Since the size is 0, the .eeprom section is not ALLOC. (Making it CONTENTS is a little but may be that is default. I am sorry but this is just my wild guess, I could be wrong.) If the size of .eeprom section is non-zero, this is what I get: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00ca 0094 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .bss 0002 00800100 00800100 015e 2**0 ALLOC 2 .eeprom 0028 0081 0081 015e 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 3 .stab 06cc 0188 2**2 CONTENTS, READONLY, DEBUGGING 4 .stabstr 0054 0854 2**0 CONTENTS, READONLY, DEBUGGING I find this useful. http://ftp.gnu.org/pub/old-gnu/Manuals/bfd-2.9.1/html_node/bfd_13.html Thanks for sharing your thoughts on overlays. Anitha ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objcopy not copying custom section...
Yes. That is where the confusion stemmed from. Hi Anitha, Last time, I didn't look exhaustively for flags in the ELF format. With the aid of readelf -e test.elf, we can see that there are more section flags in the section header: ... 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) I overlooked that before. In the sh_flags member of the Shdr struct, the ELF format does have separate explicit alloc and execute flags. I did not :-) Initially I referred to the age old System V ABI spec for reference which still had R, W and X flags. However the ELF dump showed more (as you have mentioned below). 'objdump' program works on BFD structures. The set of BFD section flags for a super set to ELF section flags. So, the dump of section headers shows BFD flags but not ELF flags. What made me mention the BFD flags is w.r.t 'CONTENTS' and 'LOAD'. These do not appear in ELF spec as section attributes. So I think objdump is just dumping ELF+ extra BFD attributes. Anitha ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objcopy not copying custom section...
-Original Message- From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org [mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Wednesday, May 25, 2011 10:34 PM To: dva...@internode.on.net; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] avr-objcopy not copying custom section... Yes. That is where the confusion stemmed from. Hi Anitha, Last time, I didn't look exhaustively for flags in the ELF format. With the aid of readelf -e test.elf, we can see that there are more section flags in the section header: ... 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) I overlooked that before. In the sh_flags member of the Shdr struct, the ELF format does have separate explicit alloc and execute flags. I did not :-) Initially I referred to the age old System V ABI spec for reference which still had R, W and X flags. However the ELF dump showed more (as you have mentioned below). 'objdump' program works on BFD structures. The set of BFD section flags for a super set to ELF section flags. So, the dump of section headers shows BFD flags but not ELF flags. What made me mention the BFD flags is w.r.t 'CONTENTS' and 'LOAD'. These do not appear in ELF spec as section attributes. So I think objdump is just dumping ELF+ extra BFD attributes. Oops, typo. Please read attributes as flags. Anitha ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objcopy not copying custom section...
On 26.05.11 01:09, Boyapati, Anitha wrote: What made me mention the BFD flags is w.r.t 'CONTENTS' and 'LOAD'. These do not appear in ELF spec as section attributes. So I think objdump is just dumping ELF+ extra BFD attributes. Oops, typo. Please read attributes as flags. Anitha, please have a look at man elf. I don't know what's in the age old System V ABI spec, but man 5 elf is from 2007, and describes Elf(64|32)_Shdr structures, containing an sh_flags member, including these bits: SHF_WRITE This section contains data that should be writable during process execution. SHF_ALLOC This section occupies memory during process execution. Some con‐ trol sections do not reside in the memory image of an object file. This attribute is off for those sections. SHF_EXECINSTR This section contains executable machine instructions. SHF_MASKPROC All bits included in this mask are reserved for processor-spe‐ cific semantics. So we can see that the ELF format does provide explicit flags for X and A. Admittedly, three sets of flags, distributed over three different structure types, with one set of flags documented as having no function, doesn't make things quite as transparent as they could be. (And being a little bit civilised, in company at least, I'll say _nothing_ about old doco. ;-) Erik P.S. If you're exiled on an M$ box, then the same guff is here: http://www.kernel.org/doc/man-pages/online/pages/man5/elf.5.html (Now I'd better start that 3 hr drive.) -- A wife asks her husband, a software engineer: Could you please go shopping for me and buy one carton of milk, and if they have eggs, get six. A short time later the husband comes back with six cartons of milk. The wife asks him, Why did you buy six cartons of milk? He replied, They had eggs. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objcopy not copying custom section...
On 26.02.11 20:22, Boyapati, Anitha wrote: ➢ asm( .section .version,\x\\n Actually, looking back, I don’t get the meaning of this. Having just now seen this post, I'll offer the following thoughts. The flags provide independent control of section attributes. If I have a separate mechanism for loading a special section (an overlay for example) then it is useful to have one or more executable sections which are not initially loaded, with only one of them being allocated space. That may be more useful on targets other than the AVR. On the AVR we do have .eeprom, which has CONTENTS, but is not ALLOC. (OK, it's not executable, but demonstrates the independence of the attributes.) How can a section be ‘executable’ without being ‘allocatable’ in ELF? An overlay would fit that case. Perhaps the question relates instead to the ELF format's ability to distinguish the cases. OK, the p_flags member of the Phdr struct only provides for X, W, and R in its bitmask, according to the elf manpage, so the question seems fair. And yet I have the following reminder of past surprises in my working notes: WARNING: In ELF executables with sections named other than .text, .data, .bss, flags default to being unset in the unrecognized sections. And then, setting x instead of ax causes the code section not to be loaded. Hmm, a readelf -l on an avr elf file lying about shows: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x94 0x 0x 0x0003a 0x0003a R E 0x1 LOAD 0xce 0x00800100 0x003a 0x0 0x0 RW 0x1 LOAD 0xce 0x00800100 0x00800100 0x0 0x0 RW 0x1 OK, that seems to confirm the p_flags limitation, but an avr-objdump -h is instructive: $ avr-objdump -h test.elf test.elf: file format elf32-avr Sections: Idx Name Size VMA LMA File off Algn 0 .text 003a 0094 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00800100 003a 00ce 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00800100 003a 00ce 2**0 ALLOC 3 .noinit 00800100 00800100 00ce 2**0 CONTENTS 4 .eeprom 0081 0081 00ce 2**0 CONTENTS Voila, even if some of the flags listed, i.e. CONTENTS, ALLOC, LOAD, don't have an obvious explicit presence in the Phdr, they are nevertheless accurate. A quick glance is as far as my current curiosity extends, but it's clear that the flags are supported by the tools, even if the details of utilisation of the ELF file format aren't immediately obvious. The only mystery seems to be whether any of these flags used earlier in the toolchain become implicit in the ELF file, but that's just an implementation detail. Erik -- Forum moderator: Did you take the [End of the world on 21.05.11] doomsday prediction seriously? Contributor: Bugger, now I have to go to work tomorrow. - Seen on ABC website on 22.05.11 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] avr-objcopy not copying custom section...
➢ asm( .section .version,\x\\n Actually, looking back, I don’t get the meaning of this. How can a section be ‘executable’ without being ‘allocatable’ in ELF? Anitha From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org [mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On Behalf Of Bill Westfield Sent: Friday, February 25, 2011 2:51 PM To: AVR-GCC-list@nongnu.org Subject: [avr-gcc-list] avr-objcopy not copying custom section... I am trying to add a version number to my program, to be located at an absolute flash address. But it looks like I can't get avr-objcopy to copy the section that I have put this data in. I have in my .C file: asm( .section .version,\x\\n optboot_version: .word MAKEVER(OPTIBOOT_MAJVER, OPTIBOOT_MINVER) \n .word 0x1234\n .section .text\n); And then I link with (for example): LDSECTIONS = -Wl,--section-start=.text=0x3e00 -Wl,--section-start=.version=0x3ffc this seems to produce a correct .elf file: optiboot_diecimila.elf: file format elf32-avr Sections: Idx Name Size VMA LMA File off Algn 0 .text 01d6 3e00 3e00 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .version 0004 3ffc 3ffc 022a 2**0 CONTENTS, READONLY, CODE : Contents of section .text: 3e00 112484b7 14be81ff d3d085e0 80938100 .$.. 3e10 82e08093 c00088e1 8093c100 86e08093 3e20 c20080e1 8093c400 8ee0bcd0 259a86e0 %... 3e30 20e33cef 91e03093 85002093 840096bb 0... . 3e40 b09bfecf 1d9aa895 8150a9f7 99249394 .P...$.. 3e50 a5e0aa2e f1e1bf2e 9dd08134 21f481e0 ...4!... 3e60 b2d083e0 1fc08234 11f484e1 03c08534 ...4...4 : Contents of section .version: 3ffc 02043412 ..4. Contents of section .debug_aranges: 2400 0200 0400 $... But objcopy seems to not include this section in output files, producing an empty hex file (data wise): BillW-MacOSX-28748 /sw/cross/bin/avr-objdump -sh optiboot_diecimila.elf | less BillW-MacOSX-28748 /sw/cross/bin/avr-objcopy -j .version -O ihex optiboot_diecimila.elf foo.hex BillW-MacOSX-28749 more foo.hex :04033E00BB :0001FF Am I missing something obvious or is this some subtle bug to be tracked down? Thanks WestfW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] avr-objcopy not copying custom section...
First, you can probably do the same thing in your C file without resorting to assembler, but doing it all in C. Second, why do you need this information to go into a hex file? Can't you just use the ELF file? -Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Bill Westfield Sent: Friday, February 25, 2011 2:21 AM To: AVR-GCC-list@nongnu.org Subject: [avr-gcc-list] avr-objcopy not copying custom section... I am trying to add a version number to my program, to be located at an absolute flash address. But it looks like I can't get avr-objcopy to copy the section that I have put this data in. I have in my .C file: asm( .section .version,\x\\n optboot_version: .word MAKEVER(OPTIBOOT_MAJVER, OPTIBOOT_MINVER) \n .word 0x1234\n .section .text\n); And then I link with (for example): LDSECTIONS = -Wl,--section-start=.text=0x3e00 -Wl,--section- start=.version=0x3ffc this seems to produce a correct .elf file: optiboot_diecimila.elf: file format elf32-avr Sections: Idx Name Size VMA LMA File off Algn 0 .text 01d6 3e00 3e00 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .version 0004 3ffc 3ffc 022a 2**0 CONTENTS, READONLY, CODE : Contents of section .text: 3e00 112484b7 14be81ff d3d085e0 80938100 .$.. 3e10 82e08093 c00088e1 8093c100 86e08093 3e20 c20080e1 8093c400 8ee0bcd0 259a86e0 %... 3e30 20e33cef 91e03093 85002093 840096bb 0... . 3e40 b09bfecf 1d9aa895 8150a9f7 99249394 .P...$.. 3e50 a5e0aa2e f1e1bf2e 9dd08134 21f481e0 ...4!... 3e60 b2d083e0 1fc08234 11f484e1 03c08534 ...4...4 : Contents of section .version: 3ffc 02043412 ..4. Contents of section .debug_aranges: 2400 0200 0400 $... But objcopy seems to not include this section in output files, producing an empty hex file (data wise): BillW-MacOSX-28748 /sw/cross/bin/avr-objdump -sh optiboot_diecimila.elf | less BillW-MacOSX-28748 /sw/cross/bin/avr-objcopy -j .version -O ihex optiboot_diecimila.elf foo.hex BillW-MacOSX-28749 more foo.hex :04033E00BB :0001FF Am I missing something obvious or is this some subtle bug to be tracked down? Thanks WestfW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
