[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.11.1: gdbsx fails



It appears that this is a known issue in gdbsx that was fixed in commit 0c9821d5c870c35aa38df7bb5e2ff54da2169b5b, as referenced here:

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@xxxxxxxxx> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.