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: Eric Weddington
Subject: RE: [avr-libc-dev] [RFC] Unified ELF file
Date: Tue, 02 Oct 2007 18:52:55 -0600


> -----Original Message-----
> From: Colin O'Flynn [mailto:address@hidden
> Sent: Tuesday, October 02, 2007 4:49 PM
> To: address@hidden
> Cc: Eric Weddington
> Subject: Re: [avr-libc-dev] [RFC] Unified ELF file
>
> Hi Eric,
>
> I'm applying your patches now, so will have more comments
> once I get the
> system working...
>
> But a quick question: what would you say to defining a macro
> such you could
> just do:
>
> FUSES  =
> {
>     .low = LFUSE_DEFAULT,
>     .high = HFUSE_DEFAULT,
>     .extended = EFUSE_DEFAULT,
> };
>
> Just as a convience to users?
>

Hmm. Might be a good idea.

I purposely chose the identifier __fuse_t (as an internal identifier)
because I may want to add stuff later. Right now the attribute is "section"
with the named section ".fuse". I'm thinking that it might be a good idea
later on to create an AVR-specific attribute __fusemem__, like we now have
__progmem__, which would put the data in the fuse memory. In doing the new
attribute, then we can create fuse_t as a struct with the new attribute. I
would rather do this kind of change later as it is more intrusive changes to
the AVR port in GCC. With the existing patches, it just changes avr-libc.

So in a sense, having a FUSES macro might be a good way to hide all the
underlying stuff and any changes later on.

Anyone else have thoughts on this?

Thanks for taking a look at this Colin! :-)

Eric Weddington






reply via email to

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