Re: Patch: Add c6x-uclinux support

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

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?

> > * I think the static functions in elf32-tic6x.c should be consistently 
> > named with an elf32_tic6x_ prefix (e.g. using_dsbt, install_rela, 
> > make_got_dynreloc).
> 
> Can do, but any particular reason? To be honest I'd kind of prefer to
> remove it from static function since it doesn't add any non-obvious
> information.

It makes it clear at the site of a function call that it's calling some 
C6X-specific function from the same file, rather than some more generic 
BFD functionality.

> > * There is a test for the undefined weak symbol handling for 
> > R_C6000_PCR_S21, in the case where the instruction has the specified form 
> > to be converted to a branch to the return address; tests for the other 
> > cases with required semantics (absolute and SB-relative relocations 
> > resolving to 0 and to the static base respectively) would be good.
> 
> The former exists in the shared library/executable testcases.

Where exactly?  There are undefined weak symbols for the ABS32 case (only, 
as far as I can see) but I can't find which dumps are verifying the 
resolution to 0 by the static linker (when it's not possible for the 
symbol to get defined at dynamic link time).

-- 
Joseph S. Myers
joseph@codesourcery.com