Re: [osv-dev] AArch64 debug build woes

2021-02-25 Thread Avi Kivity
On 25/02/2021 01.49, Waldek Kozaczuk wrote: On Wednesday, February 24, 2021 at 5:07:36 PM UTC-5 stewart.h...@dornerworks.com wrote: On Wednesday, February 24, 2021 at 4:38:02 PM UTC-5 jwkoz...@gmail.com wrote: On Wednesday, February 24, 2021 at 11:42:33 AM UTC-5

Re: [osv-dev] AArch64 debug build woes

2021-02-25 Thread Avi Kivity
On 25/02/2021 00.07, 'Stewart Hildebrand' via OSv Development wrote: On Wednesday, February 24, 2021 at 4:38:02 PM UTC-5 jwkoz...@gmail.com wrote: On Wednesday, February 24, 2021 at 11:42:33 AM UTC-5 stewart.h...@dornerworks.com wrote: On Tuesday, February 23, 2021 at

Re: [osv-dev] AArch64 debug build woes

2021-02-22 Thread Avi Kivity
On Monday, February 22, 2021 at 7:30:31 AM UTC+2 jwkoz...@gmail.com wrote: > I think I have an explanation of what is going on. Before I present it let > me recap the calling convention for aarch64: > > Caller: > >1. If we need any of x0-x18 registers, save them. They are corruptible. >

Re: [osv-dev] AArch64 debug build woes

2021-02-15 Thread Waldek Kozaczuk
For comparison fragment of zcopy_tx in release loader.elf until a call to eventfd which is after new: Dump of assembler code for function zcopy_tx(int, zmsghdr*): 0x40100da0 <+0>: stp x29, x30, [sp, #-144]! 0x40100da4 <+4>: mov x29, sp 0x40100da8

Re: [osv-dev] AArch64 debug build woes

2021-02-15 Thread Avi Kivity
On 11/02/2021 07.42, Waldek Kozaczuk wrote: 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

Re: [osv-dev] AArch64 debug build woes

2021-02-15 Thread Waldek Kozaczuk
On Mon, Feb 15, 2021 at 02:19 Nadav Har'El wrote: > On Mon, Feb 15, 2021 at 7:43 AM Waldek Kozaczuk > wrote: > >> >> >> On Sunday, February 14, 2021 at 2:33:16 PM UTC-5 Nadav Har'El wrote: >> >>> >>> You seem to be pushing registers on the stack here. Where is this stack? >>> In x86, we had

Re: [osv-dev] AArch64 debug build woes

2021-02-14 Thread Nadav Har'El
On Mon, Feb 15, 2021 at 7:43 AM Waldek Kozaczuk wrote: > > > On Sunday, February 14, 2021 at 2:33:16 PM UTC-5 Nadav Har'El wrote: > >> >> You seem to be pushing registers on the stack here. Where is this stack? >> In x86, we had separate stacks for exceptions, for nested exceptions, and >>

Re: [osv-dev] AArch64 debug build woes

2021-02-14 Thread Waldek Kozaczuk
On Sunday, February 14, 2021 at 2:33:16 PM UTC-5 Nadav Har'El wrote: > On Sat, Feb 13, 2021 at 6:24 PM Waldek Kozaczuk > wrote: > >> Hi, >> >> On Thu, Feb 11, 2021 at 9:06 AM Nadav Har'El wrote: >> >>> On Thu, Feb 11, 2021 at 7:42 AM Waldek Kozaczuk >>> wrote: >>> #1

Re: [osv-dev] AArch64 debug build woes

2021-02-14 Thread Nadav Har'El
On Sat, Feb 13, 2021 at 6:24 PM Waldek Kozaczuk wrote: > Hi, > > On Thu, Feb 11, 2021 at 9:06 AM Nadav Har'El wrote: > >> On Thu, Feb 11, 2021 at 7:42 AM Waldek Kozaczuk >> wrote: >> >>> >>> #1 0x10037954 in test_bsd_tcp1::tcp_server (this=0x206ff988) >>> at

Re: [osv-dev] AArch64 debug build woes

2021-02-13 Thread Waldek Kozaczuk
Hi, On Thu, Feb 11, 2021 at 9:06 AM Nadav Har'El wrote: > On Thu, Feb 11, 2021 at 7:42 AM Waldek Kozaczuk > wrote: > >> >> #1 0x10037954 in test_bsd_tcp1::tcp_server (this=0x206ff988) >> at /home/wkozaczuk/projects/osv/tests/tst-bsd-tcp1-zsnd.cc:114 >> >> 114 int

Re: [osv-dev] AArch64 debug build woes

2021-02-11 Thread Nadav Har'El
On Thu, Feb 11, 2021 at 7:42 AM Waldek Kozaczuk wrote: > > #1 0x10037954 in test_bsd_tcp1::tcp_server (this=0x206ff988) > at /home/wkozaczuk/projects/osv/tests/tst-bsd-tcp1-zsnd.cc:114 > > 114 int bytes2 = zcopy_tx(client_s, ); > > (gdb) p client_s > > $1 = 5 > > (gdb) p

[osv-dev] AArch64 debug build woes

2021-02-10 Thread Waldek Kozaczuk
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