public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Denis Scherbakov <denis_scherbakov@yahoo.com>
To: binutils@sources.redhat.com
Subject: What are the differences between HP's COMMON and ANSI_COMMON?
Date: Mon, 27 Apr 2009 09:46:00 -0000	[thread overview]
Message-ID: <888872.73079.qm@web65409.mail.ac4.yahoo.com> (raw)


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


      

             reply	other threads:[~2009-04-27  9:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-27  9:46 Denis Scherbakov [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=888872.73079.qm@web65409.mail.ac4.yahoo.com \
    --to=denis_scherbakov@yahoo.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).