Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson <sjohnson@sakuraindustries.com>]

As I understand the approach suggested, there will be a scan through the
sections of the ELF (.text, .data, etc), looking for VMA's of zero.  If
there is one, the test isn't performed and the debug info isn't discard.

Is it possible to to tell what section the debug info is for?  If so,
could it only not discard the debug info if it is in the particular
section with the VMA of 0.

If this is possible, I think it would be better, because (at least in my
experience) when you are trying to control the link order of things, and
have your code which starts at zero always start there, its put into a
special section like, .boot or .vectors, or some such anyway.  That
would be the only section with a VMA of 0.  Other sections, like .text
wouldn't have a VMA of zero and debug info from them with a low_pc of 0
could surely be discarded.

Even if this requires a change for future embedded programs that are
effected by this to force them to have a unique section name for the
section which starts at zero and to ensure there are no features of the
language/link used which would put .linkonce sections in this "starting
at zero" section, this would, i think, be preferrable to the current
situation.

Steven J

Frederic RISS wrote:

>On Tue, 2006-06-20 at 08:37 -0400, Daniel Jacobowitz wrote:
>  
>
>>>And I don't see much embedded bootcode needing linkonce
>>>sections.
>>>      
>>>
>>... but not probably.
>>
>>Typical for a lot of embedded devices I've worked with is to have a
>>single massive ELF image, including boot code and the entire remainder
>>of the image, and to use C++ for most of it.  I've definitely worked
>>with images where this wouldn't help.
>>    
>>
>
>I said I must have missed something in my initial mail :-)
>
>  
>
>>>>Is that an improvement?  I guess so.
>>>>        
>>>>
>>>It's certainly better than the current HAS_RELOCS check.
>>>      
>>>
>>Yes, I think so.  Want to do it, anybody?
>>    
>>
>
>I'll give it a try, if nobody beats me at it. I won't have any time in
>the upcoming days though, so don't expect it too soon.
>
>
>  
>