[avr-gcc-list] Remove .bss size from RAM segment of AVR ELF?

[Tero Sinervo]

This may seem like nitpicking but I think it should be considered as
current operation seems to conflict with ELF specification.

There's a very slight problem with ELF files that have a .bss section
regarding chip programming. If you read the RAM initialization segment
header of an ELF file you see that its filesz equals the size of .data
(which is to be written to Flash) and memsz equals the sizes of .data
and .bss combined (initialized data and data to be initialized to zero).
The ELF specification states that if memsz is greater than filesz, bytes
after filesz should be initialized to zero and follow the segment's
initialized area. This is all nice and smooth. The problem comes with
AVRs that don't actually have their RAM initialized at this point but
the data is actually written to Flash for startup code to read and
initialize the RAM with. The startup code handles .bss by zeroing that
RAM area in a loop and not by reading it from Flash memory. Currently it
is ambiguous whether the .bss part of the RAM initialization segment
should be written to Flash after the .data part or not.

This can be easily fixed in programming software but I wonder if it
should be done in AVR ELF files too. Would it be possible to exclude
.bss from AVR ELF file segments by setting memsz==filesz and only keep
.bss as a section header? That would make the program part of the ELF
file more consistent with actual programming.

Here's an example project's section and program header list:
-----
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000036 00800100 0000152c 000015a0 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 0000152c 00000000 00000000 00000074 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 000000f9 00800136 00001562 000015d6 2**0
ALLOC

Program Header:
LOAD off 0x00000074 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x0000152c memsz 0x0000152c flags r-x
LOAD off 0x000015a0 vaddr 0x00800100 paddr 0x0000152c align 2**0
filesz 0x00000036 memsz 0x0000012f flags rw-
-----


The part of ELF specification I mentioned:
-----
PT_LOAD
The array element specifies a loadable segment, described by p_filesz
and p_memsz. The bytes from the file are mapped to the beginning of the
memory segment. If the segment's memory size (p_memsz) is larger than
the file size (p_filesz), the "extra" bytes are defined to hold the
value 0 and to follow the segment's initialized area. The file size may
not be larger than the memory size. Loadable segment entries in the
program header table appear in ascending order,
sorted on the p_vaddr member.
-----

[Weddington, Eric]

-----Original Message-----
org] On Behalf Of Tero Sinervo
Sent: Thursday, June 05, 2008 7:52 AM
Subject: [avr-gcc-list] Remove .bss size from RAM segment of AVR ELF?
This may seem like nitpicking but I think it should be considered as
current operation seems to conflict with ELF specification.
There's a very slight problem with ELF files that have a .bss section
regarding chip programming. If you read the RAM
initialization segment
header of an ELF file you see that its filesz equals the size
of .data
(which is to be written to Flash) and memsz equals the sizes of .data
and .bss combined (initialized data and data to be
initialized to zero).
The ELF specification states that if memsz is greater than
filesz, bytes
after filesz should be initialized to zero and follow the segment's
initialized area. This is all nice and smooth. The problem comes with
AVRs that don't actually have their RAM initialized at this point but
the data is actually written to Flash for startup code to read and
initialize the RAM with. The startup code handles .bss by
zeroing that
RAM area in a loop and not by reading it from Flash memory.
Currently it
is ambiguous whether the .bss part of the RAM initialization segment
should be written to Flash after the .data part or not.

I can make it unambiguous: The .bss segment should NOT be written to
Flash after .data as it would take up too much space in the precious
Flash. The .data section has to be initialized from somewhere so it has
to be stored in Flash.

This can be easily fixed in programming software but I wonder if it
should be done in AVR ELF files too. Would it be possible to exclude
.bss from AVR ELF file segments by setting memsz==filesz and
only keep
.bss as a section header? That would make the program part of the ELF
file more consistent with actual programming.

What advantage does making this change bring?

[Tero Sinervo]

Post by Weddington, Eric
I can make it unambiguous: The .bss segment should NOT be written to
Flash after .data as it would take up too much space in the precious
Flash. The .data section has to be initialized from somewhere so it has
to be stored in Flash.

Yes it's only ambiguous when you look at the ELF file. If you look at
the RAM init segment you see that its paddr points to Flash memory and
its size is .data+.bss even if we only want to program .data to the Flash.

Post by Weddington, Eric

Post by Tero Sinervo
This can be easily fixed in programming software but I wonder if it
should be done in AVR ELF files too. Would it be possible to exclude
.bss from AVR ELF file segments by setting memsz==filesz and
only keep
.bss as a section header? That would make the program part of the ELF
file more consistent with actual programming.

What advantage does making this change bring?

The program part of AVR ELF files would be closer to actual device
programming by stating that you don't want to program .bss to Flash
memory. Nothing big as it's not a large obstacle to write your
programming software only to write .data and not initialize .bss.

One disadvantage I thought of is dynamic loading. The ELF files of
dynamically loaded modules shouldn't of course be affected, only
standalone embedded programs.

[Weddington, Eric]

-----Original Message-----
Sent: Friday, June 06, 2008 6:04 AM
Subject: Re: [avr-gcc-list] Remove .bss size from RAM segment
of AVR ELF?

Post by Weddington, Eric

Post by Tero Sinervo
This can be easily fixed in programming software but I

wonder if it

Post by Weddington, Eric

Post by Tero Sinervo
should be done in AVR ELF files too. Would it be possible

to exclude

Post by Weddington, Eric

Post by Tero Sinervo
.bss from AVR ELF file segments by setting memsz==filesz and only keep
.bss as a section header? That would make the program part

of the ELF

Post by Weddington, Eric

Post by Tero Sinervo
file more consistent with actual programming.

What advantage does making this change bring?

The program part of AVR ELF files would be closer to actual device
programming by stating that you don't want to program .bss to Flash
memory. Nothing big as it's not a large obstacle to write your
programming software only to write .data and not initialize .bss.

My concern is that right now, all the programming tools that I know of
already know how to deal with the current ELF file that the toolchain
generates. AVR Studio work and avrdude works. If we go about messing
around with the format of the ELF file, will we suddenly break AVR
Studio and avrdude? And for what advantage? As the saying goes: "If it
ain't broke, don't fix it."

[Tero Sinervo]

Post by Weddington, Eric
My concern is that right now, all the programming tools that I know of
already know how to deal with the current ELF file that the toolchain
generates. AVR Studio work and avrdude works. If we go about messing
around with the format of the ELF file, will we suddenly break AVR
Studio and avrdude? And for what advantage? As the saying goes: "If it
ain't broke, don't fix it."

Actually, AVR Studio's programming software is broken. Currently it
writes the RAM init segment in its entire length but as the segment only
contains enough data for .data it programs whatever there is in the ELF
file after that segment to Flash. For me it has always been debug
information. This is why I thought to suggest such a change in the first
place.

Atmel has been notified and a fix should be in the next Studio, so it
doesn't matter whether the change is made to AVR ELF files or not. I
think that's more of a philosophical question on the interpretation of
AVR ELF format.