https://sourceware.org/bugzilla/show_bug.cgi?id=19013
--- Comment #2 from Antoine Kaufmann ---
I worked around the issue for me, but still the behavior seems strange. And if
I have ld generate the 64 bit elf and then use objcopy to generate elf32-i386
the section contents also look fine, and ever
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #18 from H.J. Lu ---
(In reply to Andrew Stubbs from comment #17)
> I can check this tomorrow, but I don't think the output size is actually
> broken, as long as everything respects the input size when reading from
> input sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19013
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
You are rece
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
H.J. Lu changed:
What|Removed |Added
Attachment #8634|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=19013
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from H.J. Lu ---
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #17 from Andrew Stubbs ---
I can check this tomorrow, but I don't think the output size is actually
broken, as long as everything respects the input size when reading from input
sections. The "change something, change it back, chan
https://sourceware.org/bugzilla/show_bug.cgi?id=19008
--- Comment #10 from H.J. Lu ---
(In reply to Andi Kleen from comment #7)
> binutils mainline can't build gcc
>
> /usr/local/bin/ld-plugin: _muldi3_s.o: access beyond end of merged section
> (3168)
> /usr/local/bin/ld-plugin: _muldi3_s.o: acc
https://sourceware.org/bugzilla/show_bug.cgi?id=18997
--- Comment #3 from gingold at adacore dot com ---
> On 27 Sep 2015, at 00:54, noloader at gmail dot com
> wrote:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=18997
>
> --- Comment #2 from Jeffrey Walton ---
> (In reply to ging...@
https://sourceware.org/bugzilla/show_bug.cgi?id=19014
Bug ID: 19014
Summary: Typo in manpage of ld(1)
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assig
https://sourceware.org/bugzilla/show_bug.cgi?id=19005
--- Comment #15 from Andrew Stubbs ---
It's just because the padding is added to the output section size when
--gap-fill is set in the following snippet:
objcopy.c, copy_object()
size = bfd_section_size (obfd, osections[i]);
gap
10 matches
Mail list logo