avr-gcc-list
[Top][All Lists]
Advanced

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

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


From: Erik Christiansen
Subject: Re: [avr-gcc-list] avr-objcopy not copying custom section...
Date: Mon, 23 May 2011 17:50:06 +1000
User-agent: Mutt/1.5.20 (2009-06-14)

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           0x000094 0x00000000 0x00000000 0x0003a 0x0003a R E 0x1
  LOAD           0x0000ce 0x00800100 0x0000003a 0x00000 0x00000 RW  0x1
  LOAD           0x0000ce 0x00800100 0x00800100 0x00000 0x00000 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         0000003a  00000000  00000000  00000094  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  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.

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



reply via email to

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