[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] avr-objcopy not copying custom section...

From: Boyapati, Anitha
Subject: Re: [avr-gcc-list] avr-objcopy not copying custom section...
Date: Wed, 25 May 2011 18:55:53 +0800

>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
>> 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
>Idx Name          Size      VMA       LMA       File off  Algn
>  0 .text         0000003a  00000000  00000000  00000094  2**0
>  1 .data         00000000  00800100  0000003a  000000ce  2**0
>                  CONTENTS, ALLOC, LOAD, DATA
>  2 .bss          00000000  00800100  0000003a  000000ce  2**0
>                  ALLOC
>  3 .noinit       00000000  00800100  00800100  000000ce  2**0
>                  CONTENTS
>  4 .eeprom       00000000  00810000  00810000  000000ce  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:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000ca  00000000  00000000  00000094  2**1
  1 .bss          00000002  00800100  00800100  0000015e  2**0
  2 .eeprom       00000028  00810000  00810000  0000015e  2**0
  3 .stab         000006cc  00000000  00000000  00000188  2**2
  4 .stabstr      00000054  00000000  00000000  00000854  2**0

I find this useful. 


Thanks for sharing your thoughts on overlays.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]