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

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

RE: [avr-libc-dev] [RFC] Put avr-libc functions in unique section


From: Weddington, Eric
Subject: RE: [avr-libc-dev] [RFC] Put avr-libc functions in unique section
Date: Tue, 31 Mar 2009 10:36:23 -0600

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Dmitry K.
> Sent: Monday, March 30, 2009 10:45 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] Put avr-libc functions in 
> unique section
> 
> On Tuesday 31 March 2009 10:52, Weddington, Eric wrote:
> > Hi All,
> >
> > Attached is a patch to the current 1.6 branch.
> >
> > Currently, avr-libc functions are placed in different 
> linker sections. Most
> > of them are in .text. The floating point functions are in 
> .text.fplib. And
> > the eeprom routines are in other named subsections of .text.
> >
> > This patch places all avr-libc functions into 
> .text.avr-libc, and the
> > floating point functions in .text.avr-libc.fplib.
> 
> The alternative is the renaming after compilation: avr-objcopy.
> In this case it is not needed to add any magic words for *all* :-(
> C functions.
> What about to give a sufficient time to think/probe?
> 

I've been looking into this. I don't have a definite answer to this, but it 
seems that I would have to somehow add an avr-objcopy line after the compile 
step, which is located in all of the auto* tools magic. I'm not very 
knowledgeable about these tools. But I suspect that I would have to change this 
in more than one place. The one advantage of the patch that I posted is that 
the section information is now located in a single place, so if anyone ever 
wanted to change the section, just the one header file can be changed and then 
rebuild.

If someone wanted to change the section after it was built, they can do this, 
but it looks cumbersome as it seems to involve using avr-objcopy on each 
indivdual object file in the library and replacing the old object file with the 
new one in the library.

So, I still stick with the patch, unless someone can show me that it is an 
easier patch to do it the other way.

Eric Weddington




reply via email to

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