This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: Add c6x-uclinux support


On 03/30/2011 12:14 PM, Joseph S. Myers wrote:
> On Wed, 30 Mar 2011, Bernd Schmidt wrote:
> 
>>> 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?
>>
>> Because it contains symbols that aren't common?
> 
> # ".bss" is near (small) BSS, ".far" is far (normal) BSS, ".const" is
> # far read-only data, ".rodata" is near read-only data.  ".neardata"
> # is near (small) data, ".fardata" is (along with .data) far data.
> 
> (from elf32_tic6x_le.sh).  What is the far analogue of .scommon?

  .far            :
  {
   *(.dynfar)
   *(.far .far.* .gnu.linkonce.b.*)
   *(COMMON)				<-----------

This, I'd think. Certainly if you remove that, far common symbols are
dropped.

As far as I can tell .scommon (and its far analogue) exists only
internally in the linker, but it needs to be given some name to be
placed in the right output section (.sbss).

The linker documentation explicitly mentions that some targets use a
.scommon section. From that, and looking at elf.sc,

  SBSS=".${SBSS_NAME}         ${RELOCATING-0} :
  {
    ${RELOCATING+${SBSS_START_SYMBOLS}}
    ${CREATE_SHLIB+*(.${SBSS_NAME}2 .${SBSS_NAME}2.* .gnu.linkonce.sb2.*)}
    *(.dyn${SBSS_NAME})
    *(.${SBSS_NAME}${RELOCATING+ .${SBSS_NAME}.* .gnu.linkonce.sb.*})
    *(.scommon)
    ${RELOCATING+${SBSS_END_SYMBOLS}}
  }"

as well as a grep for ".scommon" in bfd/, I get the strong impression
that's simply how it's meant to work.

> Your 
> patch doesn't change this comment explaining the sections, and I see no 
> sign of any existing .common section name support for any target, or any 
> reason why no far analogue would be needed.

The far analogue is already handled by the linker (which knows how to
deal with _one_ common section), apparently in a somewhat "magical" way.

I don't see a reason to change the comment since it documents output
sections only, not all of the gazillion possible input section names.

> elf32-ppc.c:ppc_elf_add_symbol_hook sets SEC_IS_COMMON on .sbss.  .sbss 
> for that target corresponds to .bss for C6X, as far as the linker scripts 
> are concerned - what goes wrong with that correspondence to require 
> another section (but only one other section, not two)?

Trying that (naively replacing .scommon with .bss everywhere in
elf32-tic6x.c), I get .scomm symbols apparently being placed in .far (in
all the shlib linker tests). One immediately obvious problem is that
there's no longer anything reasonable for
elf32_tic6x_section_from_bfd_section to do. I don't know any of the PPC
ABIs, and I haven't investigated any further; we have a mechanism that
works, and works the same way as other targets.


Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]