Back to Home / #xen / 2022 / 02 / Prev Day | Next Day
#xen IRC Logs for 2022-02-04

---Logopened Fri Feb 04 00:00:58 2022
00:04-!-andyhhp [] has quit [Server closed connection]
00:05-!-andyhhp [] has joined #xen
00:05-!-andyhhp is "Andrew Cooper" on #x86 #xsxoteams #xen @#xendevel
00:24-!-genesix [~genesix@] has joined #xen
00:24-!-genesix is "purple" on #virt #llvm #ovirt #cryptoparty #xen
00:24-!-genesix [~genesix@] has quit [Remote host closed the connection]
01:06-!-jgross_ is now known as jgross
01:18-!-ChmEarl [] has quit [Quit: Leaving]
05:40-!-veremitz [] has quit [Server closed connection]
05:40-!-veremitz [] has joined #xen
05:40-!-veremitz is "Got ZNC?" on #xen @#xanmod @#dramatiq #ck
06:08-!-isodude [] has quit [Server closed connection]
06:08-!-isodude [] has joined #xen
06:08-!-isodude is "Josef Johansson" on #xen #xendevel
09:16<gwd>andyhhp: ^ This seem slike the kind of thing you might know
09:17<andyhhp>context? Seems I dropped off for a bit
09:18<gwd>andyhhp: Oh, the person asking the question seems to have left.
09:19<gwd>ChmEarl was asking if it was true that CentOS 9 has a minimum required op-code support, "basically SandyBridge with avx+aes"
09:23<andyhhp>well - Redhat introduced -mabi=x86_64-v{1,2,3} specifically so they could drop older CPUs
09:24<andyhhp>I wouldn't be surprised at all if they've started using in in C9
09:24-!-astevanato [~oftc-webi@] has joined #xen
09:24-!-astevanato is "OFTC WebIRC Client" on #xen
09:25<andyhhp>however, aes won't be part of anything they do. It's SKUd off on loads of CPUs
09:25<astevanato>Hi all.
09:27<astevanato>I'm having problem in debugging simple hello-world cpp application running on qemu->xen->domU using gdbserver. What I'm trying to achieve is to be able to debug "remotely" using gdbserver running on domU and gdb running somewhere else. The issue is that trying to exectue "si" o "n" on gdb will jump to "casual address"
09:27<astevanato>Do you know about any gdbserver limitation when executed under domain on xen?
09:28<royger>have you checked whether the same also happens when running gdbserver natively?
09:28<royger>I would be very surprised if the behavior of gdbserver changed when running in a Xen guest
09:28<royger>astevanato: ^
09:28<astevanato>You mean on dom0?
09:31<astevanato>I have tried several configuration. gdbserver on my host and gdb on domU or domO: working. Debugging the application with gdb (without gdbserver) and it works. gdbserver on domU or domO and gdb on remote NOT WORKING
09:32<astevanato>The application is a simple printf("hello world")
09:33<astevanato>Once I try to execute si (or even next) instead of going to the next line of assembler code jump always at the same location.
09:33<astevanato>This is what I get
09:33<astevanato>(gdb) si __GI___fxstat (vers=<optimized out>, fd=1, buf=0xfffffffff940) at ../sysdeps/unix/sysv/linux/wordsize-64/fxstat.c:35 ../sysdeps/unix/sysv/linux/wordsize-64/fxstat.c: No such file or directory.
09:39<astevanato>royger: ^
09:39<royger>oh, you need the sources in your target also, or else it won't be able to show the context
09:40<royger>you also need the symbols in the target I guess, or ele it won't be capable of resolving the addresses
09:40<astevanato>but which source and why? I just want to jump to addr + 4 using si
09:41<astevanato>the problem is not the source code but an unexpected trap is received.
09:41<astevanato>using set debug remote 1
09:42<astevanato>si stands for stepi
09:43<royger>and this only happens when you run gdbserver inside of a Xen guest?
09:43<astevanato>domU and dom0
09:43<astevanato>while debugging using gdb "locally" it works fine
09:43<astevanato>I mean without gdbserver
09:44<astevanato>Debugging with "set debug remote 1" that shows packets exchanged I got an unexpected trap
09:45<astevanato>answer from the server
09:45<royger>so there's some network corruption between dom0 and domU?
09:45<royger>unexpected trap in this context is not a cpu trap?
09:45<andyhhp>seeing the same instruction means somthing is mixing up trap semantics
09:46<astevanato>royger: no, there is not. Since running gdbserver on host and gdb on xen (dom0 or domU) is working fine
09:46<andyhhp>but if local gdb does work, I can't see how Xen would be related
09:47<astevanato>andyhhp: that's the point...
09:47<astevanato>I can not figure what is going on
09:48<royger>are you sing the same gdb versions for all tests?
09:48<royger>maybe try to get a network trace with wireshark or tcpdump and see what's going on?
09:49<astevanato>royger: yes they are the same
09:49<astevanato>I also tried gdbserver running on dom0/domU, spawning a new shell using ssh, running on the same dom gdb (still using target remote port) and it does not work as well
09:50<royger>does it work if you use instead?
09:54<astevanato>It is already on localhost
09:59<astevanato>Let me give you a bit of context
10:00<astevanato>I'm here
10:00<astevanato>=> 0x0000aaaaaaaa09ec <+16>: adrp x0, 0xaaaaaaaa0000
10:00<astevanato>0x0000aaaaaaaa09f0 <+20>: add x1, x0, #0xb48
10:00<royger>I've tried it locally on my dom0 and seems to work just fine, si does single step and increase IP as I would expect
10:00<astevanato>0x0000aaaaaaaa09f4 <+24>: adrp x0, 0xaaaaaaab0000
10:01<astevanato>With "set debug remote 1" we suspect that the problem is the following: Sending packet: $vCont;s:p3dc.3dc#84...Packet received: T051d:10f9ffffffff0000;1f:10f9ffffffff0000;20:f884d4f7ffff0000;thread:p3dc.3dc;core:0;
10:02<astevanato>Now I'm here
10:02<astevanato>=> 0x0000fffff7d484f8 <+24>: cmn x0, #0x1, lsl #12
10:02<astevanato>0x0000fffff7d484fc <+28>: b.hi 0xfffff7d48504 <__GI___fxstat+36>
10:02<astevanato>I would expect to be at 0x0000aaaaaaaa09f0
10:04<royger>oh, this is on Arm?
10:04<astevanato>sorry I forgot to mention it
10:04<astevanato>is that a problem?
10:05<royger>I would say no, but have little idea about Arm. I've tested it on my x86 dom0 and seems to work fine.
10:05<astevanato>the following situation works fine: gdb on dom0 and running the server on my host using qemu-aarch64-static -L ... -g port <cross compiled main>
10:06<astevanato>same happens in dom0 with using gdb <my hello world> (without gdbserver)
10:06<astevanato>I repeat: the latter works!
10:09<astevanato>Just to repeat -> gdbserver on dom0 and gdb on different shell gives
10:09<astevanato>(gdb) p/x $pc $2 = 0xaaaaaaaa09ec (gdb) si (gdb) p/x $pc $3 = 0xfffff7d484f8
10:10<andyhhp>you're best off email xen-devel@ for this
10:10<astevanato>gdb main (no target remote) gives
10:10<andyhhp>neither royger nor myself can really help you with ARM stuff like this
10:10<astevanato>(gdb) p/x $pc $1 = 0xaaaaaaaa09ec (gdb) si (gdb) p/x $pc $2 = 0xaaaaaaaa09f0
10:15<astevanato>andyhhp: I'll try to reach them if I can
10:37<julieng>astevanato: Hi, I read through the conversation. I am a little bit puzzled how Xen would be a problem here if you manage to debug your application with gdb. When sending the e-mail on Xen-devel, can you provide details on the Xen used, dom0, gdb version...? I will attempt to reproduce it on the Arm setup I have over the week-end.
10:37<julieng>(Feel free to CC me on Xen-devel: julien at
10:49-!-ChmEarl [] has joined #xen
10:49-!-ChmEarl is "Mark Pryor" on #xen ##xen-packaging #mock #packaging #virt
11:07<astevanato>julieng: I'm using petalinux (the xen built by petalinux "toolchain")
11:07<julieng>astevanato: What does "xl info" gives you?
11:07<astevanato>More or less is what this wiki states
11:08<astevanato># xl info host : xilinx-zcu102-2021_2 release : 5.10.0-xilinx-v2021.2 version : #1 SMP Tue Oct 12 09:30:57 UTC 2021 machine : aarch64 nr_cpus : 4 max_cpu_id : 3 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz : 65.000 hw_caps : 00000000:00000000:00000000:00000000:00000000:00000000:00000000:000000
11:08<astevanato>(i cannot use pastebin)
11:08<astevanato>xen_version : 4.14.3-pre
11:09<astevanato>xen_caps : xen-3.0-aarch64 xen-3.0-armv7l
11:10<astevanato>I just tried to remove xen from the equation and it works. I executed the same kernel and rootfs without xen (still using petalinux-boot and so on, just removing xen). gdbserver on this "qemu -> guest something" and gdb-multiarch on my host
11:11<astevanato>and it is just a simple hello world
11:13<julieng>astevanato: Ok. IIRC Xilinx is using Xen + their own patches. I will try it on an upstream (it will be newer though) to confirm this is also affecting upstream.
11:14<astevanato>I'll be back on monday then
11:17<astevanato>Short summary: simple hello world, gdbserver on dom0/domU, gdb/gdb-multiarch on your host or even on new shell of dom of your choice.
11:29-!-astevanato [~oftc-webi@] has quit [Remote host closed the connection]
12:11-!-ChmEarl [] has quit [Quit: Leaving]
13:26-!-ChmEarl [] has joined #xen
13:26-!-ChmEarl is "Mark Pryor" on #xen ##xen-packaging #mock #packaging #virt
18:17-!-Hunger [] has quit [Server closed connection]
18:18-!-Hunger [] has joined #xen
18:18-!-Hunger is "EG0" on #zcash-mining #zcash #xen #uml #subgraph @#shells #php #perl #pax #monotone #lvm #llvmlinux #llvm #kernelnewbies #joemberek @#hardenix #gentoo #colinux #ceph-devel #ceph #cell #ck @#bits #OpenBSD
18:40-!-weylkesiq [] has quit [Server closed connection]
18:40-!-weylkesiq [] has joined #xen
18:40-!-weylkesiq is "weylkesiq" on #tor #xen
22:37-!-jgross_ [~juergen_g@2a01:41e1:2d83:a600:15cb:776d:35cd:c35b] has joined #xen
22:37-!-jgross_ is "realname" on #xen
22:44-!-jgross [~juergen_g@2a01:41e1:2d51:c200:c765:875:d26b:c0db] has quit [Ping timeout: 480 seconds]
23:08-!-Netsplit <-> quits: d1b, overholts
23:09-!-Netsplit over, joins: overholts
23:09-!-Netsplit over, joins: d1b
---Logclosed Sat Feb 05 00:00:59 2022