Re: Patch: Add c6x-uclinux support

[Bernd Schmidt <bernds@codesourcery.com>]

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.

> Also, this directive appears to generate SHN_TIC6X_SCOMMON in object 
> files.  I don't see any sign of this in the ABI ("There are no 
> processor-specific special section indexes defined.") - exactly what 
> specification of it has been agreed with TI?

I described the mechanism, including the fact that this value should be
reserved in the ABI, to Alan Davis and he replied with "OK, good." (Nov 17).

> I also notice that the diagnostics in .scomm parsing often fail
> to follow the GNU Coding Standards (other diagnostics in tc-tic6x.c make 
> sure to avoid initial capital letters or trailing '.'; they also avoid the 
> grave accent as an opening quote, although this last style point, though 
> consistent with GCC, is outside the GNU Coding Standards).

That's probably just copied from the m32r implementation. Will fix.

> * I presume semantics for R_C6000_EHTYPE, R_C6000_PCR_H16, and 
> R_C6000_PCR_L16 are to be added in subsequent patches, since only the 
> definitions and nothing else are added in this patch.

Yes. The EH bits I've left for Paul to submit, no code exists yet for
the others as they were defined only recently.

> * 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.

> * What is the purpose of the ELF_MAXPAGESIZE change (and the logic behind 
> the choice of the new value)?  I don't think the value is of much 
> significance, but it would be good to know why the change was needed.

Can't quite remember to be honest. I've just tried with it set to 1, and
the linker behaves oddly - it to generate rather more LOAD headers, and
ld.so complains that it can't map the library if libc.so is compiled
with such a linker.

> * There is a reference to a symbol "__DYNAMIC", which I think should be 
> "_DYNAMIC".  (bfin has a reference to "__DYNAMIC", but I think that's 
> because it deviates from the gABI in having a leading underscore on symbol 
> names, unlike C6X.)

Will fix.

> * Why does elf32_tic6x_gc_sweep_hook handle R_C6000_SBR_GOT_U15_W 
> differently from R_C6000_SBR_GOT_L16_W and R_C6000_SBR_GOT_H16_W?  I 
> haven't tried to construct a testcase showing this is a problem, but it 
> seems strange for it to do so without a comment.

Seems to be an oversight.

> * 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.


Bernd