Re: failure when building a static-linked emacs25 (-nox11 on amd64)

[Joerg Sonnenberger]

On Mon, Feb 05, 2018 at 08:23:23PM +0100, Joerg Sonnenberger wrote:
> On Mon, Feb 05, 2018 at 06:24:16PM +, m...@netbsd.org wrote:
> > This sounds related:
> > https://v4.freshbsd.org/commit/netbsd/src/ipHBgqsQ9q17WJVz
> 
> That applies only for dynamic binaries with PIE.

...or I might be misremembering. Emacs should just die.

Joerg

Re: failure when building a static-linked emacs25 (-nox11 on amd64)

[Joerg Sonnenberger]

On Mon, Feb 05, 2018 at 06:24:16PM +, m...@netbsd.org wrote:
> This sounds related:
> https://v4.freshbsd.org/commit/netbsd/src/ipHBgqsQ9q17WJVz

That applies only for dynamic binaries with PIE.

Joerg

Re: failure when building a static-linked emacs25 (-nox11 on amd64)

[Greg A. Woods]

At Mon, 5 Feb 2018 18:24:16 +, m...@netbsd.org wrote:
Subject: Re: failure when building a static-linked emacs25 (-nox11 on amd64)
> 
> This sounds related:
> https://v4.freshbsd.org/commit/netbsd/src/ipHBgqsQ9q17WJVz

Yes, h http://gnats.NetBSD.org/51654

That does indeed look related!  Thank you (and David Holland and Joerg)
very much.  I'll give it a try soon and report back, but I expect it
will work just fine.

I guess emacs is the only major application that uses unexec() these
days.  Most other applications that I use these days will pay the price
of reading their VM state at run time, though of course emacs will have
much faster startup doing it the way it does.

I don't know why that didn't show up in any of my googling.  I even
tried "site:netbsd.org emacs __libc_init" and some variations, and that
still doesn't find the PR link.  Neither "site:gnats.netbsd.org emacs"
nor "site:mail-index.netbsd.org emacs crash" can find it.  Google's
spider should have found the PR and all the related mail long before now.

-- 
Greg A. Woods <gwo...@acm.org>

+1 250 762-7675   RoboHack <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>


pgpYnV2M7WybM.pgp
Description: PGP signature

Re: failure when building a static-linked emacs25 (-nox11 on amd64)

[maya]

This sounds related:
https://v4.freshbsd.org/commit/netbsd/src/ipHBgqsQ9q17WJVz

failure when building a static-linked emacs25 (-nox11 on amd64)

[Greg A. Woods]

So after having to do some debugging and sysadmin on one of my Xen
machines, I found I wanted a version of emacs installed on it, and not
having one handy I thought I'd try building a static-linked emac25-nox11.

I have long used static-linked emacs up to and including 23.2 on
NetBSD-5.  Start-up time of the static-linked binary is phenomenally
faster, especially on slower systems, and especially with the x11
version.  Some hacks are needed to make it configure, but nothing more
than fiddling with the order and completeness of "ld -l" parameters.

Unfortunately emacs25 will no longer build static-linked on a more
recent-ish NetBSD/amd64 systems.  I've not tried NetBSD-6 (I'm guessing
it wouldn't work), nor a very recent -current (though I don't expect
recent changes will help either).  I suspect it will work on NetBSD-5,
though I'll have to kick off a build of quite a few things to try it.

This is on NetBSD/amd64-7.99.34, which I think was updated 2016/07/23.

Here is what the core file looks like:

$ gdb src/bootstrap-emacs lisp/bootstrap-emacs.core
src/bootstrap-emacs:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
statically linked, for NetBSD 7.99.34, PaX: -ASLR, not stripped
lisp/bootstrap-emacs.core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), 
NetBSD-style, from 'emacs' (signal 11)
$ gdb src/bootstrap-emacs lisp/bootstrap-emacs.core
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/bootstrap-emacs...done.
[New process 1]
Core was generated by `bootstrap-emacs'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  pthread__self () at 
/build/woods/future/current-amd64-destdir/usr/include/amd64/mcontext.h:91
91  __asm volatile("movq %%fs:0, %0" : "=r" (__tmp));
(gdb) bt
#0  pthread__self () at 
/build/woods/future/current-amd64-destdir/usr/include/amd64/mcontext.h:91
#1  pthread_mutex_lock (ptm=0xba8b00 <__atexit_mutex>) at 
/building/work/woods/m-NetBSD-current/lib/libpthread/pthread_mutex.c:194
#2  0x00591140 in __cxa_atexit (func=0x5b9d30 <_fini>, arg=0x0, dso=0x0)
at /building/work/woods/m-NetBSD-current/lib/libc/stdlib/atexit.c:156
#3  0x00400227 in ___start ()
#4  0x in ?? ()
(gdb) up
#1  pthread_mutex_lock (ptm=0xba8b00 <__atexit_mutex>) at 
/building/work/woods/m-NetBSD-current/lib/libpthread/pthread_mutex.c:194
194 self = pthread__self();
(gdb) up
#2  0x00591140 in __cxa_atexit (func=0x5b9d30 <_fini>, arg=0x0, dso=0x0)
at /building/work/woods/m-NetBSD-current/lib/libc/stdlib/atexit.c:156
156 mutex_lock(&__atexit_mutex);
(gdb) print __atexit_mutex
$1 = {ptm_magic = 858980355, ptm_errorcheck = 0 '\000', ptm_pad1 = "\000\000", 
{ptm_ceiling = 0 '\000', ptm_unused = 0 '\000'}, 
  ptm_pad2 = "\000\000", ptm_owner = 0x2, ptm_waiters = 0x0, ptm_recursed = 0, 
ptm_spare2 = 0x0}
(gdb) down
#1  pthread_mutex_lock (ptm=0xba8b00 <__atexit_mutex>) at 
/building/work/woods/m-NetBSD-current/lib/libpthread/pthread_mutex.c:194
194 self = pthread__self();
(gdb) down
#0  pthread__self () at 
/build/woods/future/current-amd64-destdir/usr/include/amd64/mcontext.h:91
91  __asm volatile("movq %%fs:0, %0" : "=r" (__tmp));
(gdb) info registers 
rax0x0  0
rbx0x0  0
rcx0x82a840 8562752
rdx0x0  0
rsi0x0  0
rdi0xba8b00 12225280
rbp0x5b9d30 0x5b9d30 <_fini>
rsp0x7f7fc0b8   0x7f7fc0b8
r8 0x10101010101010172340172838076673
r9 0x8080808080808080   -9187201950435737472
r100x1  1
r110x202514
r120x0  0
r130x1  1
r140x701da5a1a808   123272635197448
r150x1  1
rip0x54ffaa 0x54ffaa 
eflags 0x10246  [ PF ZF IF RF ]
cs 0xe033   57395
ss 0xe02b   57387
ds 0x82003f 8519743
es 0x003f   -65473
fs 0x0  0
gs 0x0  0
(gdb) 


I no longer understand the differences between temacs and the "dumped"
version, but I don't see why __start() should behave differently in
each, however it seems something different is happening.  Since the
failure is still in __start(), I