Apart from the TLS issue reported here OSv can be built in the aarch64
debug mode.
Some of the tests pass as well (as on release) but there are some that seem
to fail in a similar way due to possibly wrong compiled code in kernel
possibly due to -O0.
Here is one example:
./scripts/run.py -e '/tests/tst-bsd-tcp1-zsnd.so' -c 1
page fault outside application, addr: 0x0000000000000000
[registers]
PC: 0x0000000040111e40 <zcopy_tx+84>
X00: 0x0000000000000001 X01: 0xffffa0004100f9c0 X02: 0x0000000000000008
X03: 0x0000000000000008 X04: 0x0000000000000008 X05: 0x0000000000007001
X06: 0x0000000000000000 X07: 0x00000000b71b0000 X08: 0xffff800041782aa0
X09: 0x0000000000000000 X10: 0x0000000000000002 X11: 0x0000000000000000
X12: 0x2050435420612073 X13: 0x006567617373656d X14: 0x0000000000001af8
X15: 0x0000000000000000 X16: 0x000010000005b5d0 X17: 0x0000000040111dec
X18: 0x0000000000001120 X19: 0xffffa0004100f9c0 X20: 0x0000000000000190
X21: 0x0000000000000001 X22: 0xffff800041782db8 X23: 0x0000000000000001
X24: 0xffffa000414c4b80 X25: 0xffff800041793d98 X26: 0xffff800041793da8
X27: 0x00002000006ffb00 X28: 0x000010000005a000 X29: 0xffff800041782c10
X30: 0x0000000040111e34 SP: 0xffff800041782c10 ESR: 0x0000000096000046
PSTATE: 0x0000000060000345
Aborted
[backtrace]
0x00000000400e9e14 <abort(char const*, ...)+288>
After connecting with gdb and reconstructing the stacktrace, it looks like
this:
0 0x0000000040111e40 in zcopy_tx (s=5, zm=0x1) at
bsd/sys/kern/uipc_syscalls.cc:1027
#1 0x0000100000037954 in test_bsd_tcp1::tcp_server (this=0x2000006ff988)
at /home/wkozaczuk/projects/osv/tests/tst-bsd-tcp1-zsnd.cc:114
#2 0x0000100000037a64 in test_bsd_tcp1::run()::{lambda()#1}::operator()()
const (__closure=<optimized out>) at
/home/wkozaczuk/projects/osv/tests/tst-bsd-tcp1-zsnd.cc:229
#3 std::__invoke_impl<void,
test_bsd_tcp1::run()::{lambda()#1}&>(std::__invoke_other,
test_bsd_tcp1::run()::{lambda()#1}&) (__f=...) at
/usr/include/c++/10/bits/invoke.h:60
#4 std::__invoke_r<void,
test_bsd_tcp1::run()::{lambda()#1}&>(std::__is_invocable&&,
(test_bsd_tcp1::run()::{lambda()#1}&)...) (__fn=...) at
/usr/include/c++/10/bits/invoke.h:153
#5 std::_Function_handler<void (),
test_bsd_tcp1::run()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (
__functor=...) at /usr/include/c++/10/bits/std_function.h:291
#6 0x000000004031cba8 in std::function<void ()>::operator()() const
(this=0xffffa0004168d630)
at /usr/include/c++/10/bits/std_function.h:622
#7 0x000000004043e1cc in sched::thread::main (this=0xffffa0004168d600) at
core/sched.cc:1219
#8 0x000000004043a188 in sched::thread_main_c (t=0xffffa0004168d600) at
arch/aarch64/arch-switch.hh:186
#9 0x0000000040439cf4 in sched::thread::switch_to (this=0x0) at
arch/aarch64/arch-switch.hh:28
#10 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1 0x0000100000037954 in test_bsd_tcp1::tcp_server (this=0x2000006ff988)
at /home/wkozaczuk/projects/osv/tests/tst-bsd-tcp1-zsnd.cc:114
114 int bytes2 = zcopy_tx(client_s, &zm);
(gdb) p client_s
$1 = 5
(gdb) p &zm
$2 = (zmsghdr *) 0xffff800041782d40
As you can see the test app calls zcopy_tx() which takes 2 arguments:
ssize_t zcopy_tx(int s, struct zmsghdr *zm)
the 1st one is int and has value 5 in the caller - the test app - and is
received as such
in the kernel zcopy_tx.
The second one - the address of struct zmsghdr - is problematic. On the
caller's side looks OK but when received in the kernel it is wrong - 0x1.
Why?
I saw another test crashing in a similar way when the caller (another test)
would pass 3 arguments to kernel function and 2 of those (non-addresses)
were passed correctly but the 3rd one - address one was not.
Any ideas what might be going on?
Waldek
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/4a97809f-d207-48b9-88e7-06e218e5d829n%40googlegroups.com.
