public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* What are the differences between HP's COMMON and ANSI_COMMON?
@ 2009-04-27  9:46 Denis Scherbakov
  2009-04-27 18:31 ` Steve Ellcey
  0 siblings, 1 reply; 4+ messages in thread
From: Denis Scherbakov @ 2009-04-27  9:46 UTC (permalink / raw)
  To: binutils


I am currently working on ia64-hp-hpux* linker. So far I've already managed to compile GCC
4.3.3, but Dave Korn noticed, that there might be a problem in LD that it does not handle
ANSI_COMMON symbols correctly. That is why they appear in *ABS* section.

So I wanted to ask anybody to explain me, what is the difference between these two symbols in HP and what should I expect on output?

So far I found SHN_IA_64_ANSI_COMMON in

1) elfNN_ia64_relax_section -> case with SHN_IA_64_ANSI_COMMON is never reached
2) elfNN_ia64_hpux_backend_section_from_bfd_section -> case never reached
3) elfNN_ia64_hpux_backend_symbol_processing -> case reached too late through reloc_overflow

(gdb) backtrace
#0  elf32_ia64_hpux_backend_symbol_processing (abfd=0x89fd168, asym=0x8a2916c) at elf32-ia64.c:5646
#1  0x080a18b8 in bfd_elf32_slurp_symbol_table (abfd=0x89fd168, symptrs=0x8a29140, dynamic=0) at ../../bfd/elfcode.h:1330
#2  0x080b4fac in _bfd_elf_canonicalize_symtab (abfd=0x89fd168, allocation=0x8a29140) at ../../bfd/elf.c:6561
#3  0x08083f2e in bfd_generic_link_read_symbols (abfd=0x89fd168) at ../../bfd/linker.c:754
#4  0x0806554d in vfinfo (fp=0xb7f77560, fmt=0x81101ea ":", arg=0xbfbc3154 "", is_warning=1) at ../../ld/ldmisc.c:284
#5  0x080659dc in einfo (fmt=0x81101e6 "%X%C:") at ../../ld/ldmisc.c:438
#6  0x08060bf0 in reloc_overflow (info=0x8167ec0, entry=0x89f4288, name=0x8a04a1e "varTest", reloc_name=0x8153000 "GPREL22", addend=0, abfd=0x89fd168, section=0x89ff404, address=17)
    at ../../ld/ldmain.c:1293
#7  0x0809dfe0 in elf32_ia64_relocate_section (output_bfd=0x89f1ee0, info=0x8167ec0, input_bfd=0x89fd168, input_section=0x89ff404, contents=0x89feff8 "", relocs=0x8a04a2c, local_syms=0x8a3f0e8,
    local_sections=0x89fa538) at elf32-ia64.c:5174
#8  0x080cdd00 in elf_link_input_bfd (finfo=0xbfbc3628, input_bfd=0x89fd168) at ../../bfd/elflink.c:9425
#9  0x080d0bb7 in bfd_elf_final_link (abfd=0x89f1ee0, info=0x8167ec0) at ../../bfd/elflink.c:10555
#10 0x0809c021 in elf32_ia64_final_link (abfd=0x89f1ee0, info=0x8167ec0) at elf32-ia64.c:4403
#11 0x08061d2a in ldwrite () at ../../ld/ldwrite.c:567
#12 0x0805f340 in main (argc=7, argv=0xbfbc3934) at ../../ld/ldmain.c:464

4) I added: elfNN_ia64_hpux_common_definition

#define elf_backend_common_definition  elfNN_ia64_hpux_common_definition

static bfd_boolean
elfNN_ia64_hpux_common_definition (Elf_Internal_Sym *sym)
{
  return (sym->st_shndx == SHN_COMMON
    || sym->st_shndx == SHN_IA_64_ANSI_COMMON);
}

So far I understand - it is reached exactly, where needed - just before LD decides to which section a symbol belongs.

(gdb) backtrace
#0  elf32_ia64_hpux_common_definition (sym=0x8931244) at elf32-ia64.c:4453
#1  0x080bf8d6 in elf_link_add_object_symbols (abfd=0x8930168, info=0x8167ec0) at ../../bfd/elflink.c:3943
#2  0x080c21aa in bfd_elf_link_add_symbols (abfd=0x8930168, info=0x8167ec0) at ../../bfd/elflink.c:5143
#3  0x08055627 in load_symbols (entry=0x89180e4, place=0xbfc830c4) at ../../ld/ldlang.c:2652
#4  0x08056059 in open_input_bfds (s=0x89180e4, force=0) at ../../ld/ldlang.c:3083
#5  0x0805b976 in lang_process () at ../../ld/ldlang.c:6169
#6  0x0805f303 in main (argc=7, argv=0xbfc83234) at ../../ld/ldmain.c:455

// in elflink.c:
common = bed->common_definition (isym);
// ... a few lines later
else if (isym->st_shndx == SHN_COMMON)

if I replace IF with
else if (isym->st_shndx == SHN_COMMON || common)

LD runs without errors.

Any comments are appreciated.

Denis


      

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: What are the differences between HP's COMMON and ANSI_COMMON?
  2009-04-27  9:46 What are the differences between HP's COMMON and ANSI_COMMON? Denis Scherbakov
@ 2009-04-27 18:31 ` Steve Ellcey
  0 siblings, 0 replies; 4+ messages in thread
From: Steve Ellcey @ 2009-04-27 18:31 UTC (permalink / raw)
  To: Denis Scherbakov; +Cc: binutils

Denis,

I asked around here about the difference between COMMON and ANSI_COMMON
and the answer I got was that ANSI_COMMON symbols have a higher
precedence then weak symbol definitions and regular COMMON symbols have
a lower precedence then weak definitions.  So far that is the only
difference I am aware of.

Steve Ellcey
sje@cup.hp.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: What are the differences between HP's COMMON and ANSI_COMMON?
  2009-04-27  8:03 Denis Scherbakov
@ 2009-04-27 20:40 ` Cary Coutant
  0 siblings, 0 replies; 4+ messages in thread
From: Cary Coutant @ 2009-04-27 20:40 UTC (permalink / raw)
  To: denis_scherbakov; +Cc: binutils

> I am currently working on ia64-hp-hpux* linker. So far I've already managed to compile GCC
> 4.3.3, but Dave Korn noticed, that there might be a problem in LD that it does not handle
> ANSI_COMMON symbols correctly. That is why they appear in *ABS* section.
>
> So I wanted to ask anybody to explain me, what is the difference between these two symbols in HP and what should I expect on output?

I answered this briefly in another thread.

In K&R C, a tentative declaration such as "int i;" is typically
treated as a common symbol, using the special section type SHN_COMMON.
A normal common symbol would not cause the linker to include an
archive member from a library just to satisfy an unsatisfied reference
to that symbol (although the linker would silently upgrade the
unsatisfied symbol to a common definition in that case).

When ANSI C came along, the declaration "int i;" was supposed to be
treated exactly the same as "int i = 0;" -- in other words, as a
definition, rather than a tentative definition. We found that doing
that caused too many link-time complaints about multiple definitions,
and decided that it would be better to treat such symbols as common
symbols, just like in K&R C. That ran afoul of ANSI C rules, however,
when it came to searching archive libraries -- the common symbol needs
to behave like a regular definition and trigger the inclusion of the
object file containing it. Hence, SHN_ANSI_COMMON. In all other
respects, common and ANSI common symbols should behave the same.

Bottom line, we could have just done away with tentative definitions,
and required users to correct their sources when upgrading to ANSI C.
We saw too many multiple definition errors, however, so we added this
feature as a backward compatibility measure.

(You'll see the same distinction if you look at the SOM format for
32-bit PA-RISC.)

-cary (who was to blame for all this while at HP)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* What are the differences between HP's COMMON and ANSI_COMMON?
@ 2009-04-27  8:03 Denis Scherbakov
  2009-04-27 20:40 ` Cary Coutant
  0 siblings, 1 reply; 4+ messages in thread
From: Denis Scherbakov @ 2009-04-27  8:03 UTC (permalink / raw)
  To: binutils


I am currently working on ia64-hp-hpux* linker. So far I've already managed to compile GCC
4.3.3, but Dave Korn noticed, that there might be a problem in LD that it does not handle
ANSI_COMMON symbols correctly. That is why they appear in *ABS* section.

So I wanted to ask anybody to explain me, what is the difference between these two symbols in HP and what should I expect on output?

So far I found SHN_IA_64_ANSI_COMMON in

1) elfNN_ia64_relax_section -> case with SHN_IA_64_ANSI_COMMON is never reached
2) elfNN_ia64_hpux_backend_section_from_bfd_section -> case never reached
3) elfNN_ia64_hpux_backend_symbol_processing -> case reached too late through reloc_overflow

(gdb) backtrace
#0  elf32_ia64_hpux_backend_symbol_processing (abfd=0x89fd168, asym=0x8a2916c) at elf32-ia64.c:5646
#1  0x080a18b8 in bfd_elf32_slurp_symbol_table (abfd=0x89fd168, symptrs=0x8a29140, dynamic=0) at ../../bfd/elfcode.h:1330
#2  0x080b4fac in _bfd_elf_canonicalize_symtab (abfd=0x89fd168, allocation=0x8a29140) at ../../bfd/elf.c:6561
#3  0x08083f2e in bfd_generic_link_read_symbols (abfd=0x89fd168) at ../../bfd/linker.c:754
#4  0x0806554d in vfinfo (fp=0xb7f77560, fmt=0x81101ea ":", arg=0xbfbc3154 "", is_warning=1) at ../../ld/ldmisc.c:284
#5  0x080659dc in einfo (fmt=0x81101e6 "%X%C:") at ../../ld/ldmisc.c:438
#6  0x08060bf0 in reloc_overflow (info=0x8167ec0, entry=0x89f4288, name=0x8a04a1e "varTest", reloc_name=0x8153000 "GPREL22", addend=0, abfd=0x89fd168, section=0x89ff404, address=17)
    at ../../ld/ldmain.c:1293
#7  0x0809dfe0 in elf32_ia64_relocate_section (output_bfd=0x89f1ee0, info=0x8167ec0, input_bfd=0x89fd168, input_section=0x89ff404, contents=0x89feff8 "", relocs=0x8a04a2c, local_syms=0x8a3f0e8,
    local_sections=0x89fa538) at elf32-ia64.c:5174
#8  0x080cdd00 in elf_link_input_bfd (finfo=0xbfbc3628, input_bfd=0x89fd168) at ../../bfd/elflink.c:9425
#9  0x080d0bb7 in bfd_elf_final_link (abfd=0x89f1ee0, info=0x8167ec0) at ../../bfd/elflink.c:10555
#10 0x0809c021 in elf32_ia64_final_link (abfd=0x89f1ee0, info=0x8167ec0) at elf32-ia64.c:4403
#11 0x08061d2a in ldwrite () at ../../ld/ldwrite.c:567
#12 0x0805f340 in main (argc=7, argv=0xbfbc3934) at ../../ld/ldmain.c:464

4) I added: elfNN_ia64_hpux_common_definition

#define elf_backend_common_definition  elfNN_ia64_hpux_common_definition

static bfd_boolean
elfNN_ia64_hpux_common_definition (Elf_Internal_Sym *sym)
{
  return (sym->st_shndx == SHN_COMMON
    || sym->st_shndx == SHN_IA_64_ANSI_COMMON);
}

So far I understand - it is reached exactly, where needed - just before LD decides to which section a symbol belongs.

(gdb) backtrace
#0  elf32_ia64_hpux_common_definition (sym=0x8931244) at elf32-ia64.c:4453
#1  0x080bf8d6 in elf_link_add_object_symbols (abfd=0x8930168, info=0x8167ec0) at ../../bfd/elflink.c:3943
#2  0x080c21aa in bfd_elf_link_add_symbols (abfd=0x8930168, info=0x8167ec0) at ../../bfd/elflink.c:5143
#3  0x08055627 in load_symbols (entry=0x89180e4, place=0xbfc830c4) at ../../ld/ldlang.c:2652
#4  0x08056059 in open_input_bfds (s=0x89180e4, force=0) at ../../ld/ldlang.c:3083
#5  0x0805b976 in lang_process () at ../../ld/ldlang.c:6169
#6  0x0805f303 in main (argc=7, argv=0xbfc83234) at ../../ld/ldmain.c:455

// in elflink.c:
common = bed->common_definition (isym);
// ... a few lines later
else if (isym->st_shndx == SHN_COMMON)

if I replace IF with 
else if (isym->st_shndx == SHN_COMMON || common)

LD runs without errors.

Any comments are appreciated.

Denis


      

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-04-27 20:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-27  9:46 What are the differences between HP's COMMON and ANSI_COMMON? Denis Scherbakov
2009-04-27 18:31 ` Steve Ellcey
  -- strict thread matches above, loose matches on Subject: below --
2009-04-27  8:03 Denis Scherbakov
2009-04-27 20:40 ` Cary Coutant

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).