bug#28308: Build failure on FreeBSD/aarch64

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Wed, Sep 20, 2017 at 1:51 AM, Gergely Czuczy
<gergely.czuczy@harmless.hu> wrote:

> So, here's the image for the reproduction:
> http://czg.harmless.hu/emacs/qemu-28308.gz
> You can start it with:
> qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
>                     -accel tcg,thread=single \
>                     -bios QEMU_EFI.fd -serial telnet::4444,server -nographic
> \
>                     -drive if=none,file=${image},id=hd0,format=raw \
>                     -device virtio-blk-device,drive=hd0 \
>                     -device e1000,netdev=net0 \
>                     -netdev
> tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh
>
> adjust the $image, and the last line for the networking, it just sets the IP
> address on the host device:
> ifname=$1
> ifconfig ${ifname} inet 10.219.14.254/24

I tried this on Windows, as my GNU/Linux box is underpowered. I
couldn't get the networking stuff working, but it seems to function
without that:

setlocal
set image=qemu-28308.img
set qemu="C:\Program Files\qemu\qemu-system-aarch64.exe"

%qemu% -m 4096M -cpu cortex-a57 -M virt ^
       -accel tcg,thread=single ^
       -bios QEMU_EFI.fd -serial telnet::4444,server ^
       -drive if=none,file=%image%,id=hd0,format=raw ^
       -device virtio-blk-device,drive=hd0

QEMU_EFI.fd retrieved from here: https://wiki.freebsd.org/arm64/QEMU

I tried setting a breakpoint in main, but I still landed in
tty_menu_display. Then I tried setting a breakpoint __start, after
stepping around a little I found this:

(lldb) disassemble --pc
bootstrap-emacs`__start:
->  0x40180 <+360>: mov    w0, w21
    0x40184 <+364>: mov    x1, x20
    0x40188 <+368>: mov    x2, x19
    0x4018c <+372>: bl     0x16742c                  ;
tty_menu_display + 132 at term.c:2817
(lldb) bt
* thread #1, name = 'bootstrap-emacs', stop reason = breakpoint 2.1
  * frame #0: 0x0000000000040180 bootstrap-emacs`__start(argc=9,
argv=0x0000ffffffffead0, env=0x0000ffffffffeb20,
cleanup=<unavailable>) at crt1.c:84
    frame #1: 0x0000000040390018 ld-elf.so.1`.rtld_start at rtld_start.S:41

I think that means that tty_menu_display is getting called from
__start, which should not be possible?!

Paul's suggestion of configuring with CANNOT_DUMP=yes seems to work,
although I didn't continue past compilation macroexp.el, since it's
extremely slow.