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

[Erik Christiansen]

A quick resend, to get back on the list: 

On Fri, Sep 21, 2007 at 07:28:46AM -0600, Eric Weddington wrote:
>
> This doesn't change much.
>
Yep, as stated, it modifies the original proposal as little as possible.
But by keeping only one set of default/custom assignments, it avoids the
original weaknesses:

Eric W> There are some weaknesses in this approach so far:
Eric W> - The end user has to explicitly set each fuse byte (low, high,
Eric W>  extended), even for default values. There is no automatic
Eric W>  checking if, say the low and the extended fuse bytes are set,
Eric W>  but the high fuse byte has not been set. This could potentially
Eric W>  mess up the linking (and layout) of these values, if the user
Eric W>  does not explicitly set all fuse bytes.

It is only as a solution to these problems that any tweaking of the original
method is suggested. :-)

> One should not have those line in a header file that can be included in
> multiple compilation units (.c files) because the variable would then be
> declared multiple times and one would get linker errors.

That's a very good point, but we can always handle that in a traditional
header guard:

   #ifndef  __FUSES_DONE__
   #define __FUSES_DONE__

   /* Assign all fuses  */

   #endif         /* End __FUSES_DONE__ */

> > To eliminate non-toolchain
> > causes, a minimal testcase seems useful. How does this ordinary linker
> > script snippet work in the problem case?:
> >
> >    .fuse :
> >    {
> >      KEEP(*(.fuse))
> >      KEEP(*(.lfuse))
> >      KEEP(*(.hfuse))
> >      KEEP(*(.efuse))
> >    } > fuse
> >
>
> This is essentially what I've been working with. I've attached the resulting
> avr5.x linker script that is built with the patched binutils.

Aah, it becomes very normal-looking in the end, then. The NOLOAD shouldn't be
the cause of the difference, but to claim a minimal test case it could be
worth trying to do without it.

The outcome of compiling more than one file in the error case is now the
most promising line of investigation? (Whether one should use -combine
-fwhole-program on a single file is possibly open to argument. It might
be _too_ small a testcase. ;-)

Regards,
Erik