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

---Logopened Mon Feb 07 00:00:02 2022
00:10-!-jgross_ is now known as jgross
00:43-!-Shados [~shados@shados.net] has quit [Server closed connection]
00:43-!-Shados [~shados@shados.net] has joined #xen
00:43-!-Shados is "Shados" on #virt #xen
01:16-!-Rhys [Rhys@help.lux.melted.me] has quit [Server closed connection]
01:16-!-Rhys [Rhys@help.lux.melted.me] has joined #xen
01:16-!-Rhys is "Rhys" on #xen #virt
01:17-!-Flow [~none@salem.informatik.uni-erlangen.de] has quit [Server closed connection]
01:18-!-Flow [~none@salem.informatik.uni-erlangen.de] has joined #xen
01:18-!-Flow is "none" on #xen #pwmt #mesonbuild #fai #linux-rt #llvm
02:43-!-astevanato [~oftc-webi@14.137.139.16] has joined #xen
02:43-!-astevanato is "OFTC WebIRC Client" on #xen
02:44<astevanato>Hi all.
02:45<astevanato>julieng: let me know if you had a try this weekend and you figured out what the problem was about
04:14-!-astevanato [~oftc-webi@14.137.139.16] has quit [Remote host closed the connection]
04:42-!-astevanato [~oftc-webi@14.137.139.16] has joined #xen
04:42-!-astevanato is "OFTC WebIRC Client" on #xen
05:01<julieng>astevanato: Hi, I couldn't reproduce your issue when using QEMU + Xen unstable + Debian. What I did is 1) Create a hello world app 2) Launch gdbserver 3) Create another shell 4) Launch gdb and attach it 5) Create a break point and then continue.
05:01<julieng>Did I miss any steps?
05:03<astevanato>yes you miss
05:03<astevanato>5) create break point to main (just easy way) 6) execute stepi
05:04<astevanato>or next
05:04<astevanato>if you still have the conversation of friday you can see that the address after stepi is not the $pc + 4 but is "random" (is not but still not pc + 4)
05:04<julieng>Ah, I created the breakpoint to main but then use "continue". I will attempt to use "stepi" at lunch time.
05:05<astevanato>No wait
05:05<astevanato>you did right
05:05<astevanato>(almost)
05:05<astevanato>you have to create the break point to main, then continue
05:05<astevanato>after you reach the main you have to run stepi
05:06<astevanato>as far as I know the stepi should calculate the break poin, place it and reach that point (sort of). But somehow xen mess it up
05:08<astevanato>I'll try to be even more clear. You could set the break point to main, continue (you reach the main) that you could set the break point to $pc +4 (next instruction), continue (you will reach the next instruction just fine). However, if you set the break point to main, continue and execute stepi you will not reach the next assembler instruction.
05:08<astevanato>Hope it is clear what is going on.
05:13<astevanato>julieng: ^
05:13<julieng>astevanato: It is clearer. Thank you! I should be able to test it at lunch (in ~2-3h) and report it here. I have also setup a RPI4 over the week-end with Xen running. So I will also test there to confirm this is nothing related to Xen + QEMU.
05:14<astevanato>Ok, let me know. (I can confirm it is something related to xen actually)
05:15<julieng>So Xen is not probably emulated the HW breakpoint (actually we claim there are none). But I am a bit puzzled why it would be a problem with gdbserver but not gdb.
05:15<julieng>s/probably/properly/
05:49<astevanato>julieng: Don't know what to say actually. I just hope you can reproduce it and help me to solve this issue
05:59-!-astevanato [~oftc-webi@14.137.139.16] has quit [Remote host closed the connection]
08:36-!-astevanato [~oftc-webi@14.137.139.16] has joined #xen
08:36-!-astevanato is "OFTC WebIRC Client" on #xen
08:36<astevanato>Sorry I lost the connection
08:37<astevanato>julieng: if you wrote something can you repeat it, please
08:37<julieng>astevanato: I have tried again with stepi this time. Still no issue. Here the log, https://pastebin.com/p6uvcbne
08:38<astevanato>can you repeat again the steps?
08:39<astevanato>julieng: sorry but you have the issue actually
08:40<astevanato>line 36-37 of your logs
08:42<astevanato>at line 35 it says that you are at 0x...a0784, stepi should go at 0x...a0788 (+4) and instead gdb jump somewhere else (probably 0xffffsomething) __GI___fxstat...
08:43<astevanato>so from my point of view you were able to reproduce the issue D:
08:45<astevanato>I'm missing something?
08:49<julieng>Ah, so the problem is the stepi is going further than it should. Sorry it wasn't clear to me.
08:50<julieng>I just rebooted without Xen and indeed, the stepi would break in puts@plt.
08:50<julieng>My suggestion would be to look how stepi is implemented by gdbserver and then Linux
08:54<astevanato>julieng: so you confirm that there is a problem?
08:55<astevanato>You can easy verify that this affects only gdbserver on xen with running the gdbserver somewhere else (I used qemu-aarch64-static -g <port> ...) and used gdb running on the xen dom0 targetting the remote server. With this setup you can verify that everything works fine
08:56<astevanato>let me rephrase
08:57<astevanato>You can easy verify that this affects only gdbserver on xen. You can execute the gdbserver somewhere else (I used qemu-aarch64-static -g <port> ...) and attach to it using gdb running on the xen dom0. With this setup the stepi works just fine
09:00<julieng>See above, I have already tried without Xen and yes I agree there is a bug. However, I don't exactly know where. The two potential areas of interest I can think of is Hardware Breakpoints and single stepping (from the CPU PoV).
09:02<astevanato>julieng: I also tried to `set breakpoint auto-hw off` and nothing changes
09:03<astevanato>btw I do not have the "see above" I lost all the conversation due to a network outage
09:04<julieng>Do you know how stepi work without the HW Breakpoint?
09:07<astevanato>nope, I do not
09:24<julieng>Ok. I am not sure when I will have time to have a proper look. If you need help to investigate, I would suggest to send an e-mail to xen-devel with Stefano, Bertrand and I CCed.
09:28<astevanato>I don't know if I have the auth for that.
09:28<astevanato>let's see what I can do
09:56-!-XCPngXOTeam [~XCPngXOTe@185.78.159.91] has quit [Remote host closed the connection]
09:58-!-XCPngXOTeam [~XCPngXOTe@2a01:240:ab08::2] has joined #xen
09:58-!-XCPngXOTeam is "XCPngXOTeam" on #xendevel #xen #xen-orchestra #xsxoteams
10:32-!-astevanato [~oftc-webi@14.137.139.16] has quit [Remote host closed the connection]
12:16-!-ChmEarl [~prymar56@0002b86c.user.oftc.net] has joined #xen
12:16-!-ChmEarl is "Mark Pryor" on #xen ##xen-packaging @#mock #packaging #virt
14:20-!-nj0rd [~nj0rd@mx01.private-mail-for.me] has quit [Remote host closed the connection]
14:20-!-nj0rd [~nj0rd@mx01.private-mail-for.me] has joined #xen
14:20-!-nj0rd is "nj0rd" on @#xen-devel #xen #kernelnewbies #pax
14:34-!-Netsplit charon.oftc.net <-> helix.oftc.net quits: Plam, Knorrie
14:39-!-Plam [~olivier.l@2a01:240:ab08::2] has joined #xen
14:39-!-Knorrie [knorrie@yoshi.kantoor.mendix.nl] has joined #xen
14:39-!-Plam is "olivier.lambert" on #xen
14:39-!-Knorrie is "Hans van Kranenburg" on #xen #xendevel #mch2022-logistics #debian-xen
19:26-!-ChmEarl [~prymar56@0002b86c.user.oftc.net] has quit [Quit: Leaving]
21:25-!-ChmEarl [~prymar56@0002b86c.user.oftc.net] has joined #xen
21:25-!-ChmEarl is "Mark Pryor" on #xen ##xen-packaging #mock #packaging #virt
21:49-!-genesix [~genesix@38.68.160.148] has joined #xen
21:49-!-genesix is "purple" on #virt #llvm #ovirt #cryptoparty #xen
22:34-!-jgross_ [~juergen_g@2a01:41e1:2e1f:6100:c6c3:fe27:c772:dc2a] has joined #xen
22:34-!-jgross_ is "realname" on #xen
22:41-!-jgross [~juergen_g@2a01:41e1:2deb:1900:9f8b:8327:6ebb:cf7b] has quit [Ping timeout: 480 seconds]
23:37-!-genesix [~genesix@38.68.160.148] has left #xen []
23:39-!-ChmEarl [~prymar56@0002b86c.user.oftc.net] has quit [Quit: Leaving]
---Logclosed Tue Feb 08 00:00:04 2022