avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] [RFC] Unified ELF file


From: Erik Christiansen
Subject: Re: [avr-libc-dev] [RFC] Unified ELF file
Date: Thu, 4 Oct 2007 15:03:15 +1000
User-agent: Mutt/1.5.9i

On Wed, Oct 03, 2007 at 01:50:53PM -0600, Eric Weddington wrote:
> Should it even have LOAD (the fuse data is not technically a part of
> the application)?

But we need the data. Confirming with linker scripts here, for the
experiments using just lfuse in .fuse, we find no value in the ELF file
with NOLOAD:

Disassembly of section .fuse:
   00820000 <lfuse>:

but it's there when we default to LOAD:

Disassembly of section .fuse:
00820000 <lfuse>:
  820000:   0f 00          Address 0x00820000 is out of bounds.
.word 0xffff   ; ????
  
> I don't think that DATA qualifies either, as this is not
> data that the application uses directly.

Have to agree.

> When a __fusemem__ attribute gets added to GCC, then (I think) we should be
> able to set the flags as needed.

The following works with avr-gcc:

char lfuse __attribute__ ((section (".fuse,\"a\";"))) = 0x0f;

Alan Modra describes a more intrusive variant as an evil hack, though.
(But uses it. :-) For me, the above gives:

  6 .fuse         00000001  00820000  00820000  00000184  2**0
                  ALLOC, READONLY

Note: Make it '\"aw\"' if READONLY is not desired. Your tool does change
the value, so just ALLOC may please better. But later it's ro, so
whatever.

However, I think you really only need to use this method if defaulting
an input section to a memory region, by attributes (e.g. DATA), instead
of by explicitly including the input section in an output section.

> From looking at the ld manual, I don't see how to do it with just
> linker script machinery.

That seems both easier and cleaner, to me. First, we need to stop using
NOLOAD.

Attributes which can be set in C or assembler, such as a | w | x, are
settable in the MEMORY part of the linker script, as you already do:

  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = 1K
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = 1K
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = 1K

Then simply using:

char lfuse __attribute__ ((section (".fuse"))) = 0x0f;

we have:

  6 .fuse         00000001  00820000  00820000  00000184  2**0
                  ALLOC

And hfuse etc. is just a repeat.

So in conclusion, it's easier to just let the linker script do what
comes naturally. :-)
 
I'll assist with anything that gives trouble, but I figure it'll just
work.

Erik




reply via email to

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