[Bug gold/15334] New: dwp utility has no documentation

2013-04-03 Thread law at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15334

 Bug #: 15334
   Summary: dwp utility has no documentation
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
AssignedTo: i...@airs.com
ReportedBy: l...@redhat.com
CC: ccout...@google.com
Classification: Unclassified


As far as I can tell the dwp utility has no man or texinfo documentation.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/15373] New: Gold does not support the "INSERT" command in linker scripts

2013-04-16 Thread law at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15373

 Bug #: 15373
   Summary: Gold does not support the "INSERT" command in linker
scripts
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
AssignedTo: i...@airs.com
ReportedBy: l...@redhat.com
CC: ccout...@google.com
Classification: Unclassified


Alan Modra added the "INSERT" command to the BFD based linker back in 2008, but
no corresponding support was added to gold.

Given INSERT was designed to make it easier to augment the default linker
script, it may not make sense for gold.  I'm really not in a position to make
that decision.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/15574] New: Gold is overly pedantic for dynamic references to symbols with hidden visibility

2013-06-04 Thread law at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15574

Bug ID: 15574
   Summary: Gold is overly pedantic for dynamic references to
symbols with hidden visibility
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ian at airs dot com
  Reporter: law at redhat dot com
CC: ccoutant at google dot com

$ cat t.c
#include 
#include 

void foo(void) __attribute__((visibility("hidden")));
void foo(void) {
  puts("In executable: foo - before forwarding to DSO");
  ((void(*)(void))dlsym(RTLD_DEFAULT,"foo"))();
  puts("In executable: foo - after forwarding to DSO");
}

void bar(void);

int main() {
  foo();
  bar();
}

$ cat u.c
#include 

void foo(void);
void bar(void) {
  puts("In DSO: bar");
  foo();
}

$ cat v.c
#include 

void foo(void) {
  puts("In DSO: foo");
}


$ gcc v.c -fPIC -shared -olibv.so
$ gcc u.c -fPIC -shared -olibu.so
$ gcc -D_GNU_SOURCE t.c -L. -lu -lv -ldl -Wl,-rpath,`pwd`


When linking with the bfd linker, there is no error or warning.  However,
linking with gold produces:

/usr/bin/ld: warning: hidden symbol 'foo' in /tmp/ccAF4VIi.o is referenced by
DSO ./libu.so


Note we have two definitions of "foo".  One with default visibilty in libv and
one that is hidden (main executable) and a reference to foo with default
visibility (libu). 


>From the ELF standard:

---
 None of the visibility attributes affects resolution of symbols within an
executable or shared object during link-editing -- such resolution is
controlled by the binding type. Once the link-editor has chosen its resolution,
these attributes impose two requirements, both based on the fact that
references in the code being linked may have been optimized to take advantage
of the attributes.

* First, all of the non-default visibility attributes, when applied to a
symbol reference, imply that a definition to satisfy that reference must be
provided within the current executable or shared object. If such a symbol
reference has no definition within the component being linked, then the
reference must have STB_WEAK binding and is resolved to zero.

* Second, if any reference to or definition of a name is a symbol with a
non-default visibility attribute, the visibility attribute must be propagated
to the resolving symbol in the linked object. If different visibility
attributes are specified for distinct references to or definitions of a symbol,
the most constraining visibility attribute must be propagated to the resolving
symbol in the linked object. The attributes, ordered from least to most
constraining, are: STV_PROTECTED, STV_HIDDEN and STV_INTERNAL.
---

Note carefully that visibility attributes do not affect symbol resolution
(which is controlled by the binding type).  Based on that wording I believe the
warning from gold is unnecessary and confusing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/15758] New: Gold segfault when using -q option

2013-07-19 Thread law at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15758

Bug ID: 15758
   Summary: Gold segfault when using -q option
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ian at airs dot com
  Reporter: law at redhat dot com
CC: ccoutant at google dot com

gold is segfaulting when linking the following testcode.

t.c (compile with -fPIC):

__thread int a;

void _start(void) {
a = 2;
}



Starting program: /tmp/binutils/gold/ld-new t.o -q

Breakpoint 3, gold::Sized_relobj_file<64, false>::emit_relocs_scan
(this=0xa644f0, symtab=0x7fff7980, layout=0x7fff7be0,
plocal_syms=0x77ffb468 "", p=...) at
/home/law/UPSTREAM/binutils/gold/reloc.cc:550
550   gold_assert(rr != NULL);
(gdb) c
Continuing.

Breakpoint 3, gold::Sized_relobj_file<64, false>::emit_relocs_scan
(this=0xa644f0, symtab=0x7fff7980, layout=0x7fff7be0,
plocal_syms=0x77ffb468 "", p=...) at
/home/law/UPSTREAM/binutils/gold/reloc.cc:550
550   gold_assert(rr != NULL);
(gdb) bt
#0  gold::Sized_relobj_file<64, false>::emit_relocs_scan (this=0xa644f0,
symtab=0x7fff7980, layout=0x7fff7be0, plocal_syms=0x77ffb468 "",
p=...) at /home/law/UPSTREAM/binutils/gold/reloc.cc:550
#1  0x006c5d68 in gold::Sized_relobj_file<64, false>::do_scan_relocs
(this=0xa644f0, symtab=0x7fff7980, layout=0x7fff7be0, rd=0xa4a770)
at /home/law/UPSTREAM/binutils/gold/reloc.cc:469
#2  0x006c2c7a in gold::Relobj::scan_relocs (this=0xa644f0,
symtab=0x7fff7980, layout=0x7fff7be0, rd=0xa4a770)
at /home/law/UPSTREAM/binutils/gold/object.h:1057
#3  0x006c27c1 in gold::Scan_relocs::run (this=0xa69020) at
/home/law/UPSTREAM/binutils/gold/reloc.cc:188
#4  0x0073e38b in gold::Workqueue::find_and_run_task
(this=0x7fff7630, thread_number=0) at
/home/law/UPSTREAM/binutils/gold/workqueue.cc:319
#5  0x0073e9b4 in gold::Workqueue::process (this=0x7fff7630,
thread_number=0) at /home/law/UPSTREAM/binutils/gold/workqueue.cc:495
#6  0x00404016 in main (argc=3, argv=0x7fffdb68) at
/home/law/UPSTREAM/binutils/gold/main.cc:252
(gdb) p rr
$5 = (gold::Relocatable_relocs *) 0x0


It appears the relocatable_relocs are set up in:

gold::Sized_relobj_file

  for (std::vector::const_iterator p = reloc_sections.begin();
   p != reloc_sections.end();
   ++p)
[ ... ]
 Output_section* data_section = out_sections[data_shndx];
  if (data_section == reinterpret_cast(2))
{
  // The layout for the data section was deferred, so we need
  // to defer the relocation section, too.
  const char* name = pnames + shdr.get_sh_name();
  this->deferred_layout_relocs_.push_back(
  Deferred_layout(i, name, pshdr, 0, elfcpp::SHT_NULL));
  out_sections[i] = reinterpret_cast(2);
  out_section_offsets[i] = invalid_address;
  continue;
}
  if (data_section == NULL)
{
  out_sections[i] = NULL;
  out_section_offsets[i] = invalid_address;
  continue;
}

  Relocatable_relocs* rr = new Relocatable_relocs();
  this->set_relocatable_relocs(i, rr);

We have no appropriate out_section for the section reloc section.  Thus
data_section is NULL and we call this->set_relocatable_relocs, ultimately
leading to the assertion failure.

I'm not at all familiar with the gold code, so I'm not sure how to proceed at
the moment.  Your thoughts would be appreciated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/15758] Gold segfault when using -q option

2013-11-07 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=15758

--- Comment #6 from law at redhat dot com ---
Cary -- thanks.  Your patch resolves things on my end.

Thanks again,
jeff

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16563] Corrupt .eh-frame section created when linking LTO and non-LTO objects

2014-02-12 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16563

law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/17832] strip --strip-unneeded removes needed symbol from object file in archive

2015-01-20 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=17832

law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com
 Resolution|FIXED   |DUPLICATE

--- Comment #2 from law at redhat dot com ---


*** This bug has been marked as a duplicate of bug 4716 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/4716] --strip-unneeded strips too much with relocatable ELF objects from fpc/nasm

2015-01-20 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=4716

law at redhat dot com changed:

   What|Removed |Added

 CC||acfoltzer at acfoltzer dot net

--- Comment #4 from law at redhat dot com ---
*** Bug 17832 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/12291] "ld -r" doesn't work with mixed IR/non-IR objects

2020-10-28 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=12291

law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/13298] ar --plugin doesn't work on mixed IR/non-IR input

2020-10-28 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=13298

law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/12430] IR and non-IR objects, partial linking, and undefined reference errors

2020-10-28 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=12430

law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/27073] s390 linker fails with "bad value" when building kernel

2020-12-15 Thread law at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27073

law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.