[Bug gold/21285] R_386_GOT32 for baseless case looks implemented incorrectly.

2017-03-23 Thread georgerim at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21285

--- Comment #1 from georgerim at gmail dot com ---
So gold implementation assumes that movl bar@GOT, %eax is always encoded using
0x8b, what is wrong, I think.

Because ABI says:
(https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-1.1.pdf and
https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-draft.pdf p37)
"mov name@GOT, %eax must be encoded with opcode 0x8b, not 0xa0, to allow linker
optimization."

R_386_GOT32 is not supposed to be optimized, R_386_GOT32X is used for
optimizations. That I believe means that using 0xa1 for encoding mov 0x0,%eax
with R_386_GOT32 relocation is correct. And gold behavior is broken now.

-- 
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/21294] New: Binary size regression on PPC embedded (COMMONPAGESIZE 64k)

2017-03-23 Thread floessie.mail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=21294

Bug ID: 21294
   Summary: Binary size regression on PPC embedded (COMMONPAGESIZE
64k)
   Product: binutils
   Version: 2.27
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: floessie.mail at gmail dot com
  Target Milestone: ---

Hello,

Since updating our toolchains for PPC 405, e300c3, and e500v2 we experience a
massive size increase for small binaries. Our 405 target has very small
storage, and as the rootfs contains a lot of small binaries, we can't supply
images linked with binutils 2.27 or 2.28 anymore.

I filed a bug over at crosstool-ng [1] to get some help, and Alexey Neyman was
kind enough to give me a hint to COMMONPAGESIZE. Doing some research, I found
out that it was raised from 4k to 64k in 2014 [2]. You discussed about the
impact on embedded, but it wasn't considered as an obstacle. Maybe that should
be reconsidered.

Is it possible to treat embedded, size constrained targets differently than
servers? There's a special 4k COMMONPAGESIZE for __QNXTARGET__. Or would it be
possible to add a configure option for this? Or is there already another
mechanism to alter COMMONPAGESIZE?

Kind regards,
Flössie

[1] https://github.com/crosstool-ng/crosstool-ng/issues/656
[2] https://sourceware.org/ml/binutils/2014-12/msg00165.html

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