[Bug binutils/15745] erroneous warning from readelf

2013-07-19 Thread v.garbuzov at samsung dot com 
http://sourceware.org/bugzilla/show_bug.cgi?id=15745

Slava Garbuzov  changed:

   What|Removed |Added

 CC||v.garbuzov at samsung 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/15745] erroneous warning from readelf

2013-07-19 Thread dmitry.b at samsung dot com 
http://sourceware.org/bugzilla/show_bug.cgi?id=15745

Dmitry Botcharnikov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dmitry Botcharnikov  ---
We faced with this issue running readelf on libc.so.6 for the ARM platform. I
don't think that it can be reproduced with small test case. Nevertheless patch
works, and we hope it will be commited in main trunk.

-- 
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/15745] erroneous warning from readelf

2013-07-19 Thread cvs-commit at gcc dot gnu.org 
http://sourceware.org/bugzilla/show_bug.cgi?id=15745

--- Comment #4 from cvs-commit at gcc dot gnu.org  ---
CVSROOT:/cvs/src
Module name:src
Changes by:ni...@sourceware.org2013-07-19 10:44:01

Modified files:
binutils   : ChangeLog readelf.c 

Log message:
PR binutils/15745
* readelf.c (get_unwind_section_word): Whilst searching for a
reloc section associated with an unwind section, check the type as
well as the section number.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/ChangeLog.diff?cvsroot=src&r1=1.2025&r2=1.2026
http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/readelf.c.diff?cvsroot=src&r1=1.605&r2=1.606

-- 
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

Re: Assumption about size of bfd_vma in opcodes/arm-dis.c

2013-07-19 Thread nick clifton 

Hi Mathias,

In multiple places in opcodes/arm-dis.c there is an implcit assumption
that bfd_vma has the same size as an int. See for example lines
2014-2033 in HEAD.

This can cause a segfault e.g. if binutils is compiled on i386 with
--enable-64-bit-bfd --target=arm-linux.


I am confused - how does this assumption cause a seg-fault ?

In the places where your patch changes bfd_vma to int, the value is 
being passed to print_addres_func(), which expects a bfd_vma parameter. 
so I fail to see why there is a problem.


Cheers
  Nick



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

Re: Assumption about size of bfd_vma in opcodes/arm-dis.c

2013-07-19 Thread Andreas Schwab 
Mathias Svensson  writes:

> In multiple places in opcodes/arm-dis.c there is an implcit assumption
> that bfd_vma has the same size as an int. See for example lines
> 2014-2033 in HEAD.

You are looking at some one year old sources, this has already been
fixed in 2012-07, in response to PR binutils/13135.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

___
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-07-19 Thread ccoutant at google dot com 
http://sourceware.org/bugzilla/show_bug.cgi?id=15758

Cary Coutant  changed:

   What|Removed |Added

   Assignee|ian at airs dot com|ccoutant at google dot 
com

--- Comment #1 from Cary Coutant  ---
I'll take a look.

-- 
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