Re: Patch: Add c6x-uclinux support

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 30 Mar 2011, Bernd Schmidt wrote:

> > I'm happy with the directive, and given your other comments with the 
> > section index (though it appears there must have been an omission to put 
> > this index into the latest ABI version, which postdates the discussion you 
> > mention).  But why is the additional section *name* needed?  How does it 
> > differ from .bss?
> 
> Oh, ok. To be honest - all this code is just copied from other ports, so
> I think "precedent" would be the reason. I'd prefer not to diverge
> unnecessarily from existing practice.
> 
> Looking at it now, it seems to me that common symbols require the
> behavior enabled by
> .  {* The section contains common symbols (symbols may be defined
> .     multiple times, the value of a symbol is the amount of
> .     space it requires, and the largest symbol value is the one
> .     used).  Most targets have exactly one of these (which we
> .     translate to bfd_com_section_ptr), but ECOFF has two.  *}
> .#define SEC_IS_COMMON 0x1000
> 
> This is tested in a few places in elflink.c for example.
> 
> Are you specifically worried about code in the assembler or the linker,
> or both?

I'm generally concerned that I don't understand why there are three 
sections rather than two here.  Why isn't .bss being given this property 
and used in place of .scommon?  Does it break anything for .bss not to 
have this property - or do .bss and .far already have it?  Or, 
alternatively, if you need both .scommon and .bss, why isn't a separate 
common section parallel to .far needed, so you would have four sections?  
It's not clear to me that a new section name was part of the added ABI for 
small commons (in general dependence on section names is a bit 
unfortunate, though in the absence of any better ELF way to mark small 
*data* sections as such I don't see how to avoid it here).

-- 
Joseph S. Myers
joseph@codesourcery.com