Open dkg opened 4 years ago
I've now tried it with bindgen
as built from cargo install bindgen
, with the same result:
[…]
Compiling cexpr v0.4.0
Finished release [optimized] target(s) in 1m 07s
Installing /home/dkg/.cargo/bin/bindgen
Installed package `bindgen v0.53.2` (executable `bindgen`)
warning: be sure to add `/home/dkg/.cargo/bin` to your PATH to be able to run the installed binaries
(sid_powerpc-dchroot)dkg@perotto:~$ .cargo/bin/bindgen src/bindgen-test/void.h
Segmentation fault
(sid_powerpc-dchroot)dkg@perotto:~$ gdb .cargo/bin/bindgen
GNU gdb (Debian 9.1-2) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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 "powerpc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .cargo/bin/bindgen...
(No debugging symbols found in .cargo/bin/bindgen)
(gdb) run src/bindgen-test/void.h
Starting program: /home/dkg/.cargo/bin/bindgen src/bindgen-test/void.h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 47834]
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/powerpc/powerpc32/strlen.S:98
98 ../sysdeps/powerpc/powerpc32/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/powerpc/powerpc32/strlen.S:98
#1 0x006e18c8 in std::ffi::c_str::CStr::from_ptr ()
#2 0x005328fc in bindgen::clang::extract_clang_version ()
#3 0x0056fee4 in bindgen::clang_version ()
#4 0x004532bc in bindgen::main ()
#5 0x0046e9b8 in std::rt::lang_start::{{closure}} ()
#6 0x006e1cb0 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#7 0x006e4194 in std::panicking::try::do_call ()
#8 0x006e62e0 in __rust_maybe_catch_panic ()
#9 0x006d1700 in std::rt::lang_start_internal ()
#10 0x00453808 in main ()
(gdb)
Weirdly, gdb doesn't see any arguments/parameters for any of the stack frames when i run this version of bindgen
.
Suggestions welcome!
That's interesting because we know of people building Firefox for powerpc, and that requires using bindgen...
It seems off-hand it may be an issue with clang... But anyhow I do have access to https://cfarm.tetaneutral.net/machines/list/ so can take a look, though not this week at least.
any word on this? It'd be nice to figure this out.
nudging here
@dkg it's a bit of a stretch but, are you building for 32-bit powerpc on 64-bit something? i wonder if this is a similar issue to paho.mqtt.rust#62
I too have access to the GCC compile farm. I tested on gcc112, a ppc64le machine.
$ uname -a
Linux gcc2-power8.osuosl.org 3.10.0-957.21.3.el7.ppc64le #1 SMP Tue Jun 18 16:48:04 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
I got some initially promising test failures and even a consistent segfault on header_eval_value_dependent_hpp
at 6643847b38acbd1f709ace8e07e96a2a0435c212, but then I recognized that the installed clang is version 3.4.2.
I will try to test with a newer libclang. It appears that @dkg is using clang 9.0.1, so I will try to install that.
In any case, it is perhaps a long shot that the error will appear on ppc64le since it was originally a ppc32 issue. Theoretically I could test with setarch ppc32
on ppc64le
and ppc64
machines, but I would have to build my own libclang
for those.
I will see what I can do in the next week or so.
I have made some progress in getting infrastructure in place -- I got LLVM 9.0.0 and LLVM 10.0.0 on a ppc64le machine and cargo test
ran cleanly -- but I have not yet succeeded in building in 32-bit mode, or building on a big-endian PPC machine. I can make no guarantees.
Unfortunately I am not as close to getting a 32-bit PowerPC (especially big-endian) build environment ready as I thought.
I am not actively planning on working on this for now.
@dkg, if you are able to reproduce this inside a QEMU image, I could take another look. I know that is a lot of work, though.
@kulp thanks for having taken a look at this. i don't have a qemu image handy -- my tests were done on perotto.debian.net, a 64-bit machine with a 32-bit chroot. so it might be related to https://github.com/eclipse/paho.mqtt.rust/issues/62 but i'm not sure. I don't really understand that issue well.
@ryankurte do you have any suggestions for ways i could try to do further debugging?
(see also https://bugs.debian.org/953648, on bindgen 0.51.1)
Input C/C++ Header
Bindgen Invocation
Actual Results
Expected Results
no segfault :stuck_out_tongue:
Weirdly, i note that i see no arguments for
strlen
at all in the backtrace here :/I don't know where to get the debug symbols for
std::ffi::c_str::CStr::from_ptr
either.I haven't tried this on the latest version of bindgen because debian hasn't moved to
clang_sys
0.29 yet.I recognize that not a lot of people have access to this platform, but I'm game to try any kind of debugging that you recommend, or to help an interested person get an account on the debian porterbox so you can experiment for yourself.