[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