[Bug binutils/18759] New: R_OR1K_*_PCREL should have pcrel_offset=TRUE

[whitequark at whitequark dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18759

Bug ID: 18759
   Summary: R_OR1K_*_PCREL should have pcrel_offset=TRUE
   Product: binutils
   Version: 2.25
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: whitequark at whitequark dot org
  Target Milestone: ---

Created attachment 8474
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8474&action=edit
Patch

Currently, the OpenRISC1000 relocations R_OR1K_{8,16,32}_PCREL have pc_relative
set to TRUE and pcrel_offset to FALSE. This causes incorrect linking of
.eh_frame and .gcc_except_table sections, which typically contain PC-relative
data relocations when the source file is compiled with -fPIC: with
pcrel_offset=FALSE, the relocation value is the difference between the section
start and the target, and with pcrel_offset=TRUE, the value is the difference
between the relocation position and its target. DWARF specifies the latter.

This appears to be a copy-paste bug, since the target after which elf-or1k.c
was patterned, microblaze, has pcrel_offset=TRUE for *_{8,16,32}_PCREL
relocations, as do most other targets.

It has likely gone unnoticed because no one has used exceptions with OpenRISC
before.

-- 
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/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

[whitequark at whitequark dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18759

whitequark at whitequark dot org changed:

   What|Removed |Added

 CC||whitequark at whitequark dot 
org

-- 
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/18741] Corrupted .ARM.attributes section with -meabi=gnu option

[markus.eisenmann at gmx dot at]

https://sourceware.org/bugzilla/show_bug.cgi?id=18741

markus.eisenmann at gmx dot at changed:

   What|Removed |Added

  Component|gas |binutils

--- Comment #2 from markus.eisenmann at gmx dot at ---
Further findings (IMHO - what I think):

A) bdf/elf-attrs.c: function vendor_set_obj_attr_contents():

Fix of file-attributes length; previous tag-byte not counted.

--- bdf/elf-attrs.c
+++ bdf/elf-attrs.c
@@ -183,7 +183,7 @@
   memcpy (p, vendor_name, vendor_length);
   p += vendor_length;
   *(p++) = Tag_File;
-  bfd_put_32 (abfd, size - 4 - vendor_length, p);
+  bfd_put_32 (abfd, size - 5 - vendor_length, p);
   p += 4;

   attr = elf_known_obj_attributes (abfd)[vendor];


B) bdf/elf-attrs.c: function vendor_obj_attr_size():

Even in case of vendor==OBJ_ATTR_PROC do not adjust size if there are no
attributes.

--- bdf/elf-attrs.c
+++ bdf/elf-attrs.c
@@ -104,7 +104,7 @@
 size += obj_attr_size (list->tag, &list->attr);

   /*   NUL 0x1  */
-  return ((size || vendor == OBJ_ATTR_PROC)
+  return (size
  ? size + 10 + strlen (vendor_name)
  : 0);
 }

In case of B), I'm not sure whether this is valid; Or readelf should be fixed
to recognize an empty attribute-list after the vendor-name?

Best regards from Salzburg,
Markus

P.S.: May a binutils-maintainer can review this issue and confirm, whether this
is really an bug (or not)?

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