-znocombreloc?

-znocombreloc?

[Daniel Colascione]

Does anyone remember _why_ temacs segfaults on startup unless we give ld 
this option?

Re: -znocombreloc?

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Daniel Colascione wrote:
> Does anyone remember _why_ temacs segfaults on startup unless we give ld this
> option?

It doesn't segfault for me, even when I build with -zcombreloc. I think 
-znocombreloc worked around bugs in now-obsolete versions of the GNU linker. 
See, for example:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html
https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html

Looking at recent GCC documentation it appears that this old hack should not 
matter now, so I'm inclined to remove it, as in the proposed patch (attached), 
which I tested on Fedora 24 x86-64 but have not installed.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-old-znocombreloc-hack.patch --]
[-- Type: text/x-diff; name="0001-Remove-old-znocombreloc-hack.patch", Size: 3179 bytes --]

From fe4a24b33bb72610cf6703143cf910d7eef547b6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 3 Dec 2016 21:29:06 -0800
Subject: [PATCH] Remove old -znocombreloc hack

It no longer seems relevant.  See the thread starting at:
http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00142.html
* configure.ac (LDFLAGS_NOCOMBRELOC): Remove.
(LD_SWITCH_SYSTEM_TEMACS): Do not test for -znocombreloc.
* etc/PROBLEMS: Update problem description.
---
 configure.ac | 32 --------------------------------
 etc/PROBLEMS |  7 +++----
 2 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2d116de..65b963c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1272,36 +1272,6 @@ AC_DEFUN
     ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
 fi
 
-dnl We need -znocombreloc if we're using a relatively recent GNU ld.
-dnl If we can link with the flag, it shouldn't do any harm anyhow.
-dnl Treat GCC specially since it just gives a non-fatal 'unrecognized option'
-dnl if not built to support GNU ld.
-
-dnl For a long time, -znocombreloc was added to LDFLAGS rather than
-dnl LD_SWITCH_SYSTEM_TEMACS.  That is:
-dnl * inappropriate, as LDFLAGS is a user option but this is essential.
-dnl   Eg "make LDFLAGS=... all" could run into problems,
-dnl   http://bugs.debian.org/684788
-dnl * unnecessary, since temacs is the only thing that actually needs it.
-dnl   Indeed this is where it was originally, prior to:
-dnl   http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/msg00170.html
-late_LDFLAGS="$LDFLAGS"
-if test x$GCC = xyes; then
-  LDFLAGS_NOCOMBRELOC="-Wl,-znocombreloc"
-else
-  LDFLAGS_NOCOMBRELOC="-znocombreloc"
-fi
-
-LDFLAGS="$LDFLAGS $LDFLAGS_NOCOMBRELOC"
-
-AC_MSG_CHECKING([for -znocombreloc])
-AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
-  [AC_MSG_RESULT(yes)],
-  LDFLAGS_NOCOMBRELOC=
-  [AC_MSG_RESULT(no)])
-
-LDFLAGS="$late_LDFLAGS"
-
 AC_CACHE_CHECK([whether addresses are sanitized],
   [emacs_cv_sanitize_address],
   [AC_COMPILE_IFELSE(
@@ -5176,8 +5146,6 @@ AC_DEFUN
   esac
 fi
 
-LD_SWITCH_SYSTEM_TEMACS="$LDFLAGS_NOCOMBRELOC $LD_SWITCH_SYSTEM_TEMACS"
-
 AC_SUBST(LD_SWITCH_SYSTEM_TEMACS)
 
 ## Common for all window systems
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index c9b11fbc5..82c727f 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -196,10 +196,9 @@ as Xming or Cygwin/X.
 
 It crashes on X, but runs fine when called with option "-nw".
 
-This has been observed when Emacs is linked with GNU ld but without passing
-the -z nocombreloc flag.  Emacs normally knows to pass the -z nocombreloc
-flag when needed, so if you come across a situation where the flag is
-necessary but missing, please report it via M-x report-emacs-bug.
+This was observed when Emacs was linked with old versions of GNU ld.
+If this happens, please file a bug report and mention the ld version.
+Configuring with LDFLAGS="-Wl,-znocombreloc" may fix the problem.
 
 On platforms such as Solaris, you can also work around this problem by
 configuring your compiler to use the native linker instead of GNU ld.
-- 
2.7.4

Re: -znocombreloc?

[Richard Copley]

On 4 December 2016 at 05:36, Paul Eggert <eggert@cs.ucla.edu> wrote:
> Daniel Colascione wrote:
>>
>> Does anyone remember _why_ temacs segfaults on startup unless we give ld
>> this
>> option?
>
>
> It doesn't segfault for me, even when I build with -zcombreloc. I think
> -znocombreloc worked around bugs in now-obsolete versions of the GNU linker.
> See, for example:
>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html
> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html
>
> Looking at recent GCC documentation it appears that this old hack should not
> matter now, so I'm inclined to remove it, as in the proposed patch
> (attached), which I tested on Fedora 24 x86-64 but have not installed.

Not sure where GCC and x86-64 come into it if this was for the Solaris native
linker. (Is Solaris still a thing?)

Re: -znocombreloc?

[Richard Copley]

On 4 December 2016 at 10:36, Richard Copley <rcopley@gmail.com> wrote:
> On 4 December 2016 at 05:36, Paul Eggert <eggert@cs.ucla.edu> wrote:
>> Daniel Colascione wrote:
>>>
>>> Does anyone remember _why_ temacs segfaults on startup unless we give ld
>>> this
>>> option?
>>
>>
>> It doesn't segfault for me, even when I build with -zcombreloc. I think
>> -znocombreloc worked around bugs in now-obsolete versions of the GNU linker.
>> See, for example:
>>
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html
>> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html
>>
>> Looking at recent GCC documentation it appears that this old hack should not
>> matter now, so I'm inclined to remove it, as in the proposed patch
>> (attached), which I tested on Fedora 24 x86-64 but have not installed.
>
> Not sure where GCC and x86-64 come into it if this was for the Solaris native
> linker. (Is Solaris still a thing?)

Sorry! I misread the old posts you referenced. Please ignore my reply,
it's not useful.

Re: -znocombreloc?

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 3 Dec 2016 21:36:49 -0800
> 
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html
> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html
> 
> Looking at recent GCC documentation it appears that this old hack should not 
> matter now, so I'm inclined to remove it, as in the proposed patch (attached), 
> which I tested on Fedora 24 x86-64 but have not installed.

What about other systems: Solaris, *BSD (when they use GNU ld)?  Do
they also not need this?

Andreas, you introduced the use of this switch back in Sep 2001; do
you perhaps remember the details of the original problem?

Thanks.

Re: -znocombreloc?

[Daniel Colascione]

On 12/04/2016 07:34 AM, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sat, 3 Dec 2016 21:36:49 -0800
>>
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html
>> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html
>>
>> Looking at recent GCC documentation it appears that this old hack should not
>> matter now, so I'm inclined to remove it, as in the proposed patch (attached),
>> which I tested on Fedora 24 x86-64 but have not installed.
>
> What about other systems: Solaris, *BSD (when they use GNU ld)?  Do
> they also not need this?

In any case, my guess would be that other systems won't need this switch 
with pdumper (because with pdumper, we won't be doing anything magical), 
so locally, I'll just make this stuff conditional on !CANNOT_DUMP.

Re: -znocombreloc?

[Paul Eggert]

On 12/04/2016 07:34 AM, Eli Zaretskii wrote:
> What about other systems: Solaris, *BSD (when they use GNU ld)?  Do
> they also not need this?

They did long ago, with binutils 2.14 (2003) reportedly, but I doubt 
whether they need it now. I attempted to reproduce the problem on 
Solaris 10 sparc (it ships with binutils 2.15 dated 2004) and failed to 
reproduce it. I could well have gotten the recipe wrong, though. I doubt 
whether the dwindling band of Solaris users will care about this one way 
or another, as they invariably use the Solaris linker, which does not 
need this flag.

Following up to other emails:

Yes, Solaris is still a thing and we run it on a few servers here. 
Solaris 11.3 was released last month. Oracle plans to support Solaris 10 
through 2021 and Solaris 11 through at least 2024.

Daniel's right that -znocombreloc isn't needed if CANNOT_DUMP.

Re: -znocombreloc?

[Ali Bahrami]

 > From: Eli Zaretskii <eliz@gnu.org>
 > Date: Sun, 04 Dec 2016 17:34:08 +0200
 >
 > What about other systems: Solaris, *BSD (when they use GNU ld)?  Do
 > they also not need this?


Speaking for Solaris, I don't think you need to worry
about it. It sounds like whatever bug might have been in
the GNU ld that led to turning combreloc off has been
fixed long ago, and I would bet that fix isn't really
platform specific. Aide from that, emacs is usually built
using the native ld on Solaris, so the bug was probably
never seen.

We'd prefer to have combreloc enabled, all things being equal.
It's a good, if minor, optimization for the runtime linker
at startup. If emacs has a problem with it, we'll deal with it,
and come back here to ask for help if needed.

With regard to the wider discussion of pdumper vs handling
it entirely in lisp, I'll just say that I'm thrilled to see
this being moved up the stack and out of the object file
format level. Either solution is massively simpler and
more robust than what it will replace. Thank you both for
caring about the issue enough to have this debate and see
it through. I'm confident that either outcome will be a
big improvement over the status quo.

- Ali

Re: -znocombreloc?

[Eli Zaretskii]

> From: Ali Bahrami <ali_gnu2@emvision.com>
> Date: Sun, 4 Dec 2016 20:23:30 -0700
> 
> Aside from that, emacs is usually built using the native ld on
> Solaris, so the bug was probably never seen.

This switch was only used with GNU ld.

> With regard to the wider discussion of pdumper vs handling
> it entirely in lisp, I'll just say that I'm thrilled to see
> this being moved up the stack and out of the object file
> format level. Either solution is massively simpler and
> more robust than what it will replace. Thank you both for
> caring about the issue enough to have this debate and see
> it through. I'm confident that either outcome will be a
> big improvement over the status quo.

Thanks, I;m sure you are right.

Re: -znocombreloc?

[Jeremie Courreges-Anglas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sat, 3 Dec 2016 21:36:49 -0800
>> 
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html
>> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html
>> 
>> Looking at recent GCC documentation it appears that this old hack should not 
>> matter now,

Paul, can you please point at the relevant information in the gcc
documentation?

>> so I'm inclined to remove it, as in the proposed patch (attached), 
>> which I tested on Fedora 24 x86-64 but have not installed.
>
> What about other systems: Solaris, *BSD (when they use GNU ld)?  Do
> they also not need this?

nocombreloc doesn't seem to be needed on OpenBSD/amd64, using gcc and ld
from the base system (4.2.1 and 2.17, respectively).  I've asked
for reports on other archs (emacs-25.1.90 + a patch to disable the ld
flag).

> Andreas, you introduced the use of this switch back in Sep 2001; do
> you perhaps remember the details of the original problem?
>
> Thanks.
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: -znocombreloc?

[Paul Eggert]

On 12/07/2016 03:58 PM, Jeremie Courreges-Anglas wrote:
>>> Looking at recent GCC documentation it appears that this old hack should not
>>> matter now,
> Paul, can you please point at the relevant information in the gcc
> documentation?
>
Sorry, I can't find it now. Weird. I recall reading what looked like a 
manual and inferring that -znocombreloc wasn't needed now (this was not 
plainly stated), but I can't seem to find that information now. I 
thought it was the GCC manual, but perhaps it was another GNU manual, or 
perhaps I was reading the GCC Wiki. Sorry.