[Bug ld/28903] LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later

[jbthiel at gmail dot com]

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

--- Comment #1 from John B Thiel <jbthiel at gmail dot com> ---
Here are some notes from my FPC bug report, pulled forward for easy reference. 
I also put 2 linker maps in the other bug report, good-2.35.2  and bad-2.36.1, 
let me know if you need them attached again here.  Will also supply other
object files, maps, traces, etc. let me know if anything needed.

===

Minimal helloworld.pas generates faulty executable that immediately seg faults.

GDB shows it breaks before main:
(gdb) break main
Breakpoint 1 at 0x401064
(gdb) run
During startup program terminated with signal SIGSEGV, Segmentation fault.

I have debugged some and it seems related to binutils-2.36.1  or binutils-libs.
The problem also occurs with binutils-2.37.  Reverting back to binutils-2.35.2
restores correct function, no segfault.

===

The linker maps I attached above are from default linker ld, which is ld.bfd.
Now I tested 2 other linkers, by giving fpc -sh, then editing the ppas.sh to
call a different linker, namely:

  ld.gold  (also from binutils, same version as ld.bfd the default ld)
  ld.lld-12.0.1

Both these linkers give Segmentation Fault in the exe, on BOTH binutils-2.35.2
and 2.36.1.

So only LD.BFD linker was working at all, and as of 2.36.1 it stopped working
too.

Note that LD.LLD is not in the binutils package, rather in sys-devel/lld.
So the link problem seems to be at a deeper layer, not only binutils.

The link.res shows there are only 3 input files:

INPUT(
/usr/local/fpc-2.6.4//lib/fpc/2.6.4/units/x86_64-linux/rtl/prt0.o
myprog.o
/usr/local/fpc-2.6.4//lib/fpc/2.6.4/units/x86_64-linux/rtl/system.o
)

The prt0.o, system.o, are the stock ones from the binary Linux FPC264
distribution:

  1712 Mar  3  2014
/usr/local/fpc-2.6.4//lib/fpc/2.6.4/units/x86_64-linux/rtl/prt0.o
  361692 Mar  3  2014
/usr/local/fpc-2.6.4//lib/fpc/2.6.4/units/x86_64-linux/rtl/system.o

Also, I briefly started examining objdump of the executables. It seems like
(not sure yet), the correct startup code and entry point are present in the
segfaulting exe.  This suggests a problem with the startup trap used to jump
there, or maybe some attributes of the code segment are not being set right.  I
have read elsewhere of evolving security initiatives with kernel changes, that
are tightening requirements on the structure/permissions of executable code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.