Re: Patch: Add c6x-uclinux support

[Bernd Schmidt <bernds@codesourcery.com>]

On 03/29/2011 06:13 PM, Joseph S. Myers wrote:
> On Tue, 29 Mar 2011, Bernd Schmidt wrote:
> 
>> On 03/29/2011 12:33 AM, Joseph S. Myers wrote:
>>> On Fri, 11 Mar 2011, Bernd Schmidt wrote:
>>>
>>>> Also included in this patch is support for a new assembler directive,
>>>> ".scomm", used to better support small-data common symbols as required
>>>> by the ABI. There's also a small assembler bugfix for -mgenerate-rel.
>>>
>>> Why exactly is a .scommon section needed in addition to .bss and .far - 
>>> how does it differ from those two sections?
>>
>> What happens on other targets is that the linker decides, based on size,
>> whether a common symbol goes into near or far BSS. That doesn't work for
>> the C6X ABI where considerations such as symbol type come into play.
>> Hence, the compiler must make the decision.
> 
> 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?


Bernd