Re: Xen 4.11.1: gdbsx fails

[Matt Leinhos <matthew.leinhos@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3527 bytes --]

It appears that this is a known issue in gdbsx that was fixed in commit
0c9821d5c870c35aa38df7bb5e2ff54da2169b5b, as referenced here:
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21769.html

However, that commit is not included in the RELEASE-4.11.1 tag. In fact, I
show tools/debuggers/gdbsx as being untouched since Apr 2018 in that tag.

--Matt


On Fri, Apr 5, 2019 at 4:48 PM Matt Leinhos <matthew.leinhos@gmail.com>
wrote:

> Greetings:
>
> I've encountered a problem running gdb + gdbsx on Xen 4.11.1, running
> Linux kernel 4.18.0-15 on Ubuntu 18.04. Pertinent info is below.
>
> I've observed this behavior with gdb 8.0, 8.1.1 and 8.2. I've also seen it
> on Xen 4.9.2. In short, something is broken with my system, but I don't
> know how to investigate.
>
> Thanks in advance for any help!
>
> --Matt
>
>
> Here's my guest config file:
>
> $ cat xen-vms/ub1804-dev.hvm
> type = "hvm"
> name = "ub18-dev-work"
>
> # Initial and max memory allocation (MB)
> memory = 2048
> maxmem = 2048
>
> vcpus = 1
> acpi = 1
> apic = 1
> # values: disabled, mixed, external, limited
> altp2m = "mixed"
> vif = [ 'bridge=xenbr0' ]
> disk = [ 'phy:/dev/ubuntu-vg/xen_ubuntu_dev,xvda,w'
>
> ,'file:/home/matt/iso/ubuntu-18.04.1-desktop-amd64.iso,hdc:cdrom,r' ]
> boot = 'c' # hard disk (c) / cdrom (d)
> console = 1
> on_poweroff = "destroy"
> on_reboot   = "restart"
> on_crash    = "preserve"
>
>
> Here are the two usages of gdbsx (both from Dom0). Note that domain 2 is
> 64 bit.
>
> # xl list
> Name                                        ID   Mem VCPUs      State
> Time(s)
> Domain-0                                     0 30098     8     r-----
> 8724.5
> ub18-dev-work                                2  2040     1     -b----
> 24.9
>
> This is a sanity check....
> # gdbsx -c 2 64 0
> ===> Context for DOMID:2
>
> --> VCPU:0
> rip:ffffffff9b1f52e6 rsp:ffffffff9bc03e10 flags:0000000000000246
> rax:ffffffff9b1f4ff0 rbx:0000000000000000 rcx:ffffffff9bc6ff60
> rdx:0000000000066e16 rsi:ffffffff9bc2ebc8 rdi:0000000000000000
> r08:00000000505563be r09:0000000000000000 r10:0000000000000008
> r11:0000000000000008 r12:0000000000000000 r13:0000000000000000
> r14:0000000000000000 r15:0000000000000000 rbp:ffffffff9bc03e10
> cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
> gs:0000000000000000
>
> Call Trace:
>    [ffffffff9b1f52e6]
>    [ffffffff9bc03e38]
>    [ffffffff9b1f5010]
>    [ffffffff9be85ee0]
>    [ffffffff9bc03e48]
>    [ffffffff9a8394c5]
>    [ffffffff9bc03e58]
>    [ffffffff9b1f544c]
>    [ffffffff9bc03ea0]
>    [ffffffff9a8c3c84]
>    [ffffffff9bf8c920]
>
> This is the actual usage that fails
> # gdbsx -a 2 64 3333
> Listening on port 3333
> Remote debugging from host 127.0.0.1
> readchar: Got EOF
> Detaching from guest
> Exiting.. Remote side has terminated connection
>
>
> And here's the corresponding usage of gdb that led to the failure in gdbsx
> (again, from Dom0):
>
> $ gdb -q
> Currently logging to "/home/matt/gdb.log".
> Logs will overwrite the log file.
> Output will be logged and displayed.
> gdb> set architecture i386:x86-64
> The target architecture is assumed to be i386:x86-64
> gdb> target remote localhost:3333
> Remote debugging using localhost:3333
> warning: No executable has been specified and target does not support
> determining executable automatically.  Try using the "file" command.
> Truncated register 26 in remote 'g' packet
> gdb> show version
> GNU gdb (Ubuntu 8.2-0ubuntu1~18.04) 8.2
> Copyright (C) 2018 Free Software Foundation, Inc.
>

[-- Attachment #1.2: Type: text/html, Size: 4903 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel