[Bug ld/14299] Allow output sections to be spread over multiple memory regions

2017-02-22 Thread marcus.shawcroft at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=14299

Marcus Shawcroft  changed:

   What|Removed |Added

 CC||marcus.shawcroft at gmail dot 
com

--- Comment #1 from Marcus Shawcroft  ---
Aside from performance enhancement aspect of this issue there is a more
sinister correctness issue associated with this problem.

In the case of the cortex-m4 an attempt to perform an unaligned access across
the boundary will result in a memory fault.

A common use case is to aggregate the two regions into a single RAM bank
(ignoring any potental performance optimization that might be had), in this
scenario there is no obvious way to write a link script that fills up both RAM
regions but ensures that no object is placed straddling the boundary.

mbed-os and several other platform software implementations address this issue
by writing a linker script that partitions the RAM into the two output regions
and then manually hardwire input sections to the two output sections.  This
solution is fragile and regularly fails with the first region overflowing,
resulting in further tweaks to the linker script.

zephyr-os also have this issue and currently have no workaround.

-- 
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 gas/20744] [PPC] Incorrect relocation for VLE-instructions

2017-02-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20744

--- Comment #8 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_28-branch branch has been updated by Alan Modra
:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=55ff522848fef1fc5323060fd042d0988e71d4b9

commit 55ff522848fef1fc5323060fd042d0988e71d4b9
Author: Alan Modra 
Date:   Thu Feb 23 12:20:42 2017 +1030

Correct VLE 16D and SDAREL relocations

PR 20744
bfd/
* elf32-ppc.c (ppc_elf_howto_raw): Correct dst_mask on all VLE
16D relocations.
(ppc_elf_vle_split16): Correct field mask and shift for 16D relocs.
(ppc_elf_relocate_section): Correct calculation for VLE SDAREL
relocs.
ld/
* testsuite/ld-powerpc/vle-reloc-2.s: Use r6 for last insn of
each group.
* testsuite/ld-powerpc/vle-reloc-2.d: Update for above change
and sdarel reloc fix.

-- 
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 gas/20744] [PPC] Incorrect relocation for VLE-instructions

2017-02-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20744

--- Comment #7 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Alan Modra :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5499c7c71cc403a1deff90b79ab41d17efc5c4cc

commit 5499c7c71cc403a1deff90b79ab41d17efc5c4cc
Author: Alan Modra 
Date:   Thu Feb 23 12:20:42 2017 +1030

Correct VLE 16D and SDAREL relocations

PR 20744
bfd/
* elf32-ppc.c (ppc_elf_howto_raw): Correct dst_mask on all VLE
16D relocations.
(ppc_elf_vle_split16): Correct field mask and shift for 16D relocs.
(ppc_elf_relocate_section): Correct calculation for VLE SDAREL
relocs.
ld/
* testsuite/ld-powerpc/vle-reloc-2.s: Use r6 for last insn of
each group.
* testsuite/ld-powerpc/vle-reloc-2.d: Update for above change
and sdarel reloc fix.

-- 
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 gas/20744] [PPC] Incorrect relocation for VLE-instructions

2017-02-22 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20744

Alan Modra  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Alan Modra  ---
You're correct, there is yet another bug with the VLE support of these
relocations.

-- 
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 gas/16288] Specifying an ISA in a .set directive causes a warning if "lower" than set from command-line

2017-02-22 Thread ma...@linux-mips.org
https://sourceware.org/bugzilla/show_bug.cgi?id=16288

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Maciej W. Rozycki  ---
This seems to have been fixed long ago with:

commit 919731affbef19fcad8dddb0a595bb05755cb345
Author: mfortune 
Date:   Tue May 20 13:28:20 2014 +0100

Add MIPS .module directive

so I am closing 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 gas/20744] [PPC] Incorrect relocation for VLE-instructions

2017-02-22 Thread alfedotov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20744

Alexander Fedotov  changed:

   What|Removed |Added

 CC||alfedotov at gmail dot com

--- Comment #5 from Alexander Fedotov  ---
Hi Alan
Are you sure about shift = 9 ?

It seems shift should be 10.

-- 
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/21180] ld segfault for microblaze when --gc-sections is used

2017-02-22 Thread wbx at openadk dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=21180

wbx at openadk dot org changed:

   What|Removed |Added

 Target||microblaze
   Host||x86_64
  Build||x86_64

--- Comment #2 from wbx at openadk dot org ---
You don't need microblaze hardware, the problem appear while cross-compiling
from x86_64 to microblaze. The segfault happens without any assertion failure
while trying to cross-compile libnss or kmod.

You can reproduce using for example Buildroot or OpenADK buildsystem targeting 
Qemu system for microblaze.

git clone git://buildroot.org/buildroot 
cd buildroot
git revert fceb1afd5dda45cf180f22877a6ab0e51d1b3dac
make qemu_microblazeel_mmu_defconfig
make menuconfig
--> choose Target Packages - Libraries - Crypto - libnss
make V=1

Wait a while for the segfault happening.

-- 
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/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local

2017-02-22 Thread ma...@linux-mips.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20828

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #35 from Maciej W. Rozycki  ---
Fixed again, hopefully for real this time.

-- 
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/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local

2017-02-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20828

--- Comment #34 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Maciej W. Rozycki :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=902e9fc76a0ec9f642cefa71ef88cca1c675ad54

commit 902e9fc76a0ec9f642cefa71ef88cca1c675ad54
Author: Maciej W. Rozycki 
Date:   Tue Feb 21 01:46:42 2017 +

PR ld/20828: Move symbol version processing ahead of GC symbol sweep

Complement commit b531344c34b0 ("PR ld/20828: Reorder the symbol sweep
stage of section GC") and commit 81ff47b3a546 ("PR ld/20828: Fix linker
script symbols wrongly forced local with section GC") and move symbol
version processing ahead of the symbol sweep stage of section GC, all in
`bfd_elf_size_dynamic_sections', so that version symbols created stay in
the global scope and are not output as local symbols to the dynamic
symbol table in the presence of corresponding symbol definitions pulled
from a DSO involved in a link.

Consolidate the whole of symbol version processing into a single block
from all parts scattered across the function and rearranging the local
variables used as necessary, however leaving the setting of dynamic
entries associated with the DT_VERDEF, DT_VERDEFNUM, DT_VERNEED and
DT_VERNEEDNUM tags and the SEC_EXCLUDE flag for unused `.gnu.version'
section in the original places.

With the rearrangement of code blocks `Elf_Internal_Verneed *t' would
shadow the previous definition of `struct bfd_elf_version_tree *t', so
rename the former variable to `vn'.

bfd/
PR ld/20828
* elflink.c (bfd_elf_size_dynamic_sections): Move symbol version
processing ahead of the call to `elf_gc_sweep_symbol'.

ld/
PR ld/20828
* testsuite/ld-elf/pr20828-d.sd: New test.
* testsuite/ld-elf/pr20828-e.sd: New test.
* testsuite/ld-elf/pr20828-v.od: New test.
* testsuite/ld-elf/pr20828-v.ver: New test version script.
* testsuite/ld-elf/pr20828-v.ld: New test linker script.
* testsuite/ld-elf/pr20828.ld: Add `.gnu.version' and
`.gnu.version_d'.
* testsuite/ld-elf/shared.exp: Run the new tests.

-- 
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 gprof/21189] gprof doesn't work with code built with PIE

2017-02-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21189

--- Comment #3 from Nick Clifton  ---
(In reply to H.J. Lu from comment #2)
> The load address of PIE is determined at run-time and changes for
> each run.  But the format of gmon.out doesn't support the changing load
> address.

All the more reason then for mcount() to adjust its output in order to allow
for the run-time address bias.

-- 
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/21193] objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1

2017-02-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21193

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Hi Richard,

  There is no definitive specification for the .gnu_debuglink section, but I
  think that it is clear that it is meant to be aligned on a 4-byte boundary
  so that the CRC value can be read using 32-bit reads.

  So I have checked in a patch to update the bfd_create_gnu_debuglink_section
  function to add the required alignment.

  Is that sufficient, or is there anything else that needs to be updated ?

Cheers
  Nick

-- 
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/21193] objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1

2017-02-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21193

--- Comment #1 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=758d96d834ba725461abf4be36df9f13e0815054

commit 758d96d834ba725461abf4be36df9f13e0815054
Author: Nick Clifton 
Date:   Wed Feb 22 17:28:33 2017 +

Align .gnu_debuglink sections on a 4-byte boundary.

PR binutils/21193
* opncls.c (bfd_create_gnu_debuglink_section): Give the newly
created section 4-byte alignment.

-- 
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 gprof/21189] gprof doesn't work with code built with PIE

2017-02-22 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21189

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
The load address of PIE is determined at run-time and changes for
each run.  But the format of gmon.out doesn't support the changing load
address.

-- 
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/21193] New: objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1

2017-02-22 Thread rguenth at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21193

Bug ID: 21193
   Summary: objcopy --add-gnu-debuglink adds .gnu_debuglink with
ALIGN 1
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

int main(){}
> gcc t.c -g
> objcopy --add-gnu-debuglink=a.out.debug a.out
> readelf -S a.out
...
  [36] .gnu_debuglinkPROGBITS   1d90
   0010     0 0 1

you can see ALIGN 1.  eu-strip -g creates it with ALIGN 4:

  [31] .gnu_debuglinkPROGBITS   1834
   0010     0 0 4

and this is what RPMs sepdebugcrcfix expects:

  const uint8_t *zerop = memchr (data->d_buf, '\0', data->d_size);
  const uint8_t *crcp = (zerop == NULL
 ? NULL
 : (const uint8_t *) ((uintptr_t) (zerop + 1 + 3)
  & -4));
  if (crcp + 4 != (uint8_t *) data->d_buf + data->d_size)
{
  raise (SIGSTOP);
  error (0, 0, _("invalid format of section \"%s\" # %zu in \"%s\""),
 scnname, elf_ndxscn (scn), fname);
  continue;
}

appearantly also objcopy pads the string part to 4 bytes but the above also
requires alignment (on the libelf representation which honors ALIGN).

I will fix the tool but it would be nice to check the "specification" of
.gnu_debuglink as if that padding implicitely assumes alignment of the
section (why would we pad otherwise?).

-- 
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/21180] ld segfault for microblaze when --gc-sections is used

2017-02-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21180

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Would it be possible for you to provide us with a testcase that demonstrates
this problem ?  I do not have access to a microblaze system so I cannot just
download and build nss.

Also - is an assertion being triggered, and if so, what is the message and
line number associated with the assertion failure ?

-- 
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 gprof/21189] gprof doesn't work with code built with PIE

2017-02-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21189

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Matthias,

> Since --enabled-default-pie was enabled in Debian for GCC 6, gprof no longer
> works.

I think that this might be a glibc bug.  Specifically in their implementation
of mcount() for PIE environments.

Running "gprof -d infloop | grep main" shows that main starts at address 0x860:

  [get_src_info] 0x860 -> infloop.c:1 (main)
  [core_create_function_syms] 15 main 0x860

And that it covers 0x2f bytes:

  [symtab_finalize] 0x860-0x88f main

But, the data in the gmon.out file us using much higher addresses:

  [hist_read_rec] n_lowpc 0x4004e0 n_highpc 0x400718 ncnt 144

  [assign_samples] bin_low_pc=0x40063a, bin_high_pc=0x40063e, bin_count=18
  [assign_samples] bin_low_pc=0x40063e, bin_high_pc=0x400642, bin_count=38
  [assign_samples] bin_low_pc=0x400646, bin_high_pc=0x40064a, bin_count=82
  [assign_samples] total_time 138.00

Of course I may be wrong - I am not an expert on gprof - but it does look to me
like the contents of the gmon.out file are wrong.

Alternatively maybe gprof needs a way compute a starting address bias for PIE
executables.

Cheers
  Nick

-- 
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/20666] [libopcodes][Aarch64] BFI instruction decoded as bad BFC instruction

2017-02-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20666

--- Comment #4 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Jan Beulich :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=11648de5a91658326748dea1e4965559e9bd7a0f

commit 11648de5a91658326748dea1e4965559e9bd7a0f
Author: Jan Beulich 
Date:   Wed Feb 22 10:36:05 2017 +0100

aarch64: actually copy first operand in convert_bfc_to_bfm()

Commit 93562a343c ("[AArch64] PR target/20666, fix wrong encoding of
new introduced BFC pseudo") changed the destination operand to 0,
making the whole function invocation a no-op. We really want to copy
operand 0 (a register) to operand 1 (an immediate before coming here),
even if right now this likely is only a latent 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 binutils/21191] objcopy --only-keep-debug creates non-monotonically increasing section offsets

2017-02-22 Thread rguenth at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=21191

--- Comment #2 from Richard Biener  ---
(In reply to Alan Modra from comment #1)
> File offset for a SHT_NOBITS section is irrelevant.
> 
> Note that this "bug" can also occur with ld.  You don't want to waste space
> in the output file with padding for NOBITS sections, but glibc ld.so checks
> that p_vaddr and p_offset agree modulo pagesize, even for segments with
> p_filesz zero.  Thus p_offset needs to be adjusted to pacify glibc. 
> p_offset is derived from sh_offset so we adjust sh_offset too.
> 
> We could zero all the NOBITS sh_offset values for this specific case of
> --only-keep-debug, but I don't see the point given that ld will create out
> of order sh_offset.
> 
> What tool was complaining about sh_offset?  Fix it please.

It is DWZ complaining, I've sent a fix to Jakub zeroing sh_offset (and ignoring
NOBITS sections for its sanity checks).  He didn't like it too much but we'll
see.

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