On Thu, Feb 17, 2022 at 3:54 AM Nick Clifton <ni...@redhat.com> wrote:
> Hi John, > > > It appears that LD in binutils versions after 2.35 is producing segfault > executables with Free Pascal 2.6.4. You cannot build a working HelloWorld. > > Please could you file a bug report about this issue using the binutils > bugzilla system: > https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils > That site is not creating new accounts, it says email overseers@... I have done that now to request a new account, to file this bug. Note this mailing list at https://lists.gnu.org/mailman/listinfo/bug-binutils claims "This is the official address to which to report bugs in the GNU binutils." But I noticed most of the msgs here seem to be echoes of updates from that other tracker. So thanks for responding here. Someone should update the info pages on what is the real binutils bugtracker. > > I have written up a full report, please see > > https://gitlab.com/freepascal.org/fpc/source/-/issues/39324 < > https://gitlab.com/freepascal.org/fpc/source/-/issues/39324> > > Has anyone been able to track down the exact cause of the segmentation > fault ? For example is the loader rejecting the executable as being > malformed, or is the startup code branching off into a random memory > location, or something else ? > I think I'm the only one who has analyzed it to that depth. I was able to invoke gdb on the executable, but it never gets into main(). I think it is jumping to random memory location. I wrote a few other speculations in the other bug report, though I'm not very familiar with the intricacies of obj/exe/loader. A paragraph of my analysis from the other bug report: > "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." It was a pretty good debugging achievement already to reduce/diagnose it down to binutils/ld and simple helloworld.pas. The actual large scale effect was that one of my applications which has been working reliably for years, came to a screeching segfault halt during development one day. I tracked it down to recent Gentoo update, specifically binutils, ld. If you need some exe/object files, traces, etc. let me know and I will try to supply. The helloworld test case I gave is very easy to reproduce if you install FPC 2.6.4. > > The Free Pascal developers believe this is a regression of a similar LD > bug that previously occurred and was fixed in LD. > Do you know which bug this was? > The suggestion from FPC devs so far is that it relates to: https://wiki.freepascal.org/User_Changes_3.2.0#GNU_Binutils_2.19.1_or_later_are_required_by_default GNU Binutils 2.19.1 or later are required by default Old behaviour: The compiler invocation of the linker always resulted in a warning stating "did you forget -T?" New behaviour: The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later. Reason: Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues). Remedy: If you have a system with an older version of GNU Binutils, you can use the new -X9 command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that. --- https://gitlab.com/freepascal.org/fpc/source/-/commit/4564bffb85e5947cf7bdfa3e2c67bc032775d0c5 * use binutils 2.19+ linker script "augmentation" functionality to specify how the fpc sections have to be linked *on Linux*. This prevents the "did you forget -T" warnings from ld, and in general is more correct than our previous approach of specifying a complete linker script without -T and hoping that there won't be any unexpected interactions with ld's built-in linker script (fixed version of r31664, thanks to Alan Modra) o use the new -X9 command line option to generate linker scripts that are compatible with binutils older than 2.19 (reverts to the old behaviour) Note it is *not* confirmed that this is the actual issue here. This prior issue relates to something in binutils 2.19, whereas I have fully confirmed this current issue is between binutils-2.35 and 2.36. Maybe it's the same problem, or not. > > They put a workaround/redesign in later versions of FreePascal, the 3.x > series, but are unable to backport their fix to FPC 2.6.4. > Not to be mean, but if the 3.x series is working, why worry about > the 2.6.4 release ? If people want to use that release, can't they > also stick with binutils 2.35 ? > Because FPC/Lazarus is a giant self-contained software stack, the approximate equivalent of binutils + gcc + libc + an entire graphical windows/component/object system. The 3.x series changed significantly, requiring at minimum application code updates to track it, and has unresolved bugs that make it unsatisfactory for my application. In short, 2.6.4 works for my application, 3.x does not. So I cannot use the 3.x series for certain applications, and it's completely infeasible to lock whole system on an older binutils, since the entire Gentoo/Linux infrastructure relies on binutils and tracks the leading edge. I believe the FPC team builtin their own linker in the later series 3.x, specifically to avoid this external dependency on LD, but the older version relies on LD. So the binutils LD linker must continue to work for FPC 2.6.4. > > Cheers > Nick > >
