This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Patch: Add c6x-uclinux support
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