From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Leinhos Subject: Re: Xen 4.11.1: gdbsx fails Date: Sat, 6 Apr 2019 16:00:17 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8891381806626683677==" Return-path: Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hCsQR-0007qK-DQ for xen-devel@lists.xenproject.org; Sat, 06 Apr 2019 21:00:31 +0000 Received: by mail-wm1-x335.google.com with SMTP id z24so10702280wmi.5 for ; Sat, 06 Apr 2019 14:00:30 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============8891381806626683677== Content-Type: multipart/alternative; boundary="000000000000a3216a0585e2e40a" --000000000000a3216a0585e2e40a Content-Type: text/plain; charset="UTF-8" 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 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. > --000000000000a3216a0585e2e40a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It appears that this is a known issue in gdbsx that was fi= xed in commit=C2=A00c9821d5= c870c35aa38df7bb5e2ff54da2169b5b, a= s referenced here:

However, that comm= it is not included in the RELEASE-4.11.1 tag. In fact, I show tools/debugge= rs/gdbsx as being untouched since Apr 2018 in that tag.

--Matt


On Fri, Apr 5, 2019 at 4:48 PM Matt Leinho= s <matthew.leinhos@gmail.co= m> wrote:
Greetings:

I've encountered a problem running = gdb + gdbsx on Xen=20 4.11.1, running Linux kernel 4.18.0-15 on Ubuntu 18.04. Pertinent info=20 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


He= re's my guest config file:

$ cat xen-vms/ub1804-dev.hvm
type = =3D "hvm"
name =3D "ub18-dev-work"

# Initial = and max memory allocation (MB)
memory =3D 2048
maxmem =3D 2048
vcpus =3D 1
acpi =3D 1
apic =3D 1
# values: disabled, mixed, exte= rnal, limited
altp2m =3D "mixed"=C2=A0
vif =3D [ 'brid= ge=3Dxenbr0' ]
disk =3D [ 'phy:/dev/ubuntu-vg/xen_ubuntu_dev,xvd= a,w'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,'file:/home/mat= t/iso/ubuntu-18.04.1-desktop-amd64.iso,hdc:cdrom,r' ]
boot =3D '= c' # hard disk (c) / cdrom (d)
console =3D 1
on_poweroff =3D &quo= t;destroy"
on_reboot=C2=A0=C2=A0 =3D "restart"
on_cras= h=C2=A0=C2=A0=C2=A0 =3D "preserve"


Here are the two us= ages of gdbsx (both from Dom0). Note that domain 2 is 64 bit.

# xl l= ist
Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ID=C2=A0=C2=A0 Mem VCPUs=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 State=C2=A0=C2=A0 Time(s)
Domain-0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 30098=C2=A0=C2=A0=C2=A0=C2=A0 8=C2=A0= =C2=A0=C2=A0=C2=A0 r-----=C2=A0=C2=A0=C2=A0 8724.5
ub18-dev-work=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0 2040=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0= =C2=A0=C2=A0=C2=A0 -b----=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 24.9

This is a sanity check....
# gdbsx -c 2 64 0
=3D=3D=3D= > Context for DOMID:2

--> VCPU:0
rip:ffffffff9b1f52e6 rsp:f= fffffff9bc03e10 flags:0000000000000246
rax:ffffffff9b1f4ff0 rbx:00000000= 00000000 rcx:ffffffff9bc6ff60
rdx:0000000000066e16 rsi:ffffffff9bc2ebc8 = rdi:0000000000000000
r08:00000000505563be r09:0000000000000000 r10:00000= 00000000008
r11:0000000000000008 r12:0000000000000000 r13:00000000000000= 00
r14:0000000000000000 r15:0000000000000000 rbp:ffffffff9bc03e10
cs:= 0000000000000010 ds:0000000000000000 fs:0000000000000000 gs:000000000000000= 0

Call Trace:
=C2=A0=C2=A0 [ffffffff9b1f52e6]
=C2=A0=C2=A0 [ff= ffffff9bc03e38]
=C2=A0=C2=A0 [ffffffff9b1f5010]
=C2=A0=C2=A0 [fffffff= f9be85ee0]
=C2=A0=C2=A0 [ffffffff9bc03e48]
=C2=A0=C2=A0 [ffffffff9a83= 94c5]
=C2=A0=C2=A0 [ffffffff9bc03e58]
=C2=A0=C2=A0 [ffffffff9b1f544c]=
=C2=A0=C2=A0 [ffffffff9bc03ea0]
=C2=A0=C2=A0 [ffffffff9a8c3c84]
<= div>=C2=A0=C2=A0 [ffffffff9bf8c920]

This is the ac= tual usage that fails
# gdbsx -a 2 64 3333
Listening on port 33= 33
Remote debugging from host 127.0.0.1
readchar: Got EOF
Detachin= g from guest
Exiting.. Remote side has terminated connection


= And here's the corresponding usage of gdb that led to the failure in gd= bsx (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 targe= t architecture is assumed to be i386:x86-64
gdb> target remote localh= ost:3333
Remote debugging using localhost:3333
warning: No executable= has been specified and target does not support
determining executable a= utomatically.=C2=A0 Try using the "file" command.
Truncated re= gister 26 in remote 'g' packet
gdb> show version
GNU gdb (= Ubuntu 8.2-0ubuntu1~18.04) 8.2
Copyright (C) 2018 Free Software Foundati= on, Inc.
--000000000000a3216a0585e2e40a-- --===============8891381806626683677== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============8891381806626683677==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A903CC10F06 for ; Sat, 6 Apr 2019 21:00:55 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 65120213F2 for ; Sat, 6 Apr 2019 21:00:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KPzc6n+o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65120213F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hCsQT-0007qP-7w; Sat, 06 Apr 2019 21:00:33 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hCsQR-0007qK-DQ for xen-devel@lists.xenproject.org; Sat, 06 Apr 2019 21:00:31 +0000 X-Inumbo-ID: 0259aae6-58af-11e9-92d7-bc764e045a96 Received: from mail-wm1-x335.google.com (unknown [2a00:1450:4864:20::335]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 0259aae6-58af-11e9-92d7-bc764e045a96; Sat, 06 Apr 2019 21:00:30 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id z24so10702280wmi.5 for ; Sat, 06 Apr 2019 14:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iwkbrct55KTUSWu4mwTmypT37PP1Jl2hd+YCnW2AJ58=; b=KPzc6n+ofSumB4mTVMuj2LNboFuS8iCfh+tt1quspiRItaY7lWDPKB7m066Jed+TDC M6rdZO8QJC7QRvbfqXP6QgQG4BZR2ksvbXv2OeitVv5/ImNWpPrCz6rCRjaMt10KltHX 4agGx9nmPHwD4//E+DrJinca2VigDAybJxF8gXmMkRSdOqh1lL2uMr7sDM4pZHko/q70 IjRTU5WNT/8lrDd0l+tvpgkGbQ8qnuJn21TPwHPvE/PI5ICT2uYODhrBmaXSKBvDq2XN ywPwWhL3RUgyWLjIBC1qvqYOae2b4CMFmdfIn6jKasMwD8qoNIKfe/nTxea1VJxZUDfP EPLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iwkbrct55KTUSWu4mwTmypT37PP1Jl2hd+YCnW2AJ58=; b=mn5Lt30LC6IMdy6l4zgIwc8urdfOjJuBO/MNcjbHYRQMfJCPgEd/rBmR4ADBMiA3ql e9/OiFY+fE6tiIg251bYnbyZOjFDJHewL0GRkOiTD9ZlIROG5RUtH3tSKWRI1FWmQOCT T/YGIPBJ7Lr0coIFtqmqjaTLgpIkdtqgCDWBkeGPx6zbay1kuEM2G125VpV5P05mqVIC H9tIpIhXrlInxPHg3A67dH5OYVa24ROmEPxUKKfUCXc0LoTNglxWJSxfejHP7L/mToRi mXgVhjGqy+gj5yAJKxsoE07LgttLHSvgz1ndDzWI/21ubT6dcsaniIqsmzno0eeuijNT evlw== X-Gm-Message-State: APjAAAVg4iA1CS52JHK0cQ/O0Wom/MUO+iGh/jhugXYZM5ndO8cA+rMK dOffEbcX8F1Ac2I+6xCXPAGnzJLwNfauqBmjpAYx7tmk X-Google-Smtp-Source: APXvYqyplMK6CTVk7QpgRMW58brQ/HmPekmZ4rLAKODCoitKeszgaF/5fzvO0HANWRbRKTzJaU6gp+Oiw5rVyAXqe/o= X-Received: by 2002:a7b:c3c9:: with SMTP id t9mr11788302wmj.131.1554584428550; Sat, 06 Apr 2019 14:00:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matt Leinhos Date: Sat, 6 Apr 2019 16:00:17 -0500 Message-ID: To: xen-devel@lists.xenproject.org Subject: Re: [Xen-devel] Xen 4.11.1: gdbsx fails X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8891381806626683677==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Message-ID: <20190406210017.bB-xar9LiLxhBCj33MptpQuyk4pCocLccXJQ_DazP0k@z> --===============8891381806626683677== Content-Type: multipart/alternative; boundary="000000000000a3216a0585e2e40a" --000000000000a3216a0585e2e40a Content-Type: text/plain; charset="UTF-8" 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 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. > --000000000000a3216a0585e2e40a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It appears that this is a known issue in gdbsx that was fi= xed in commit=C2=A00c9821d5= c870c35aa38df7bb5e2ff54da2169b5b, a= s referenced here:

However, that comm= it is not included in the RELEASE-4.11.1 tag. In fact, I show tools/debugge= rs/gdbsx as being untouched since Apr 2018 in that tag.

--Matt


On Fri, Apr 5, 2019 at 4:48 PM Matt Leinho= s <matthew.leinhos@gmail.co= m> wrote:
Greetings:

I've encountered a problem running = gdb + gdbsx on Xen=20 4.11.1, running Linux kernel 4.18.0-15 on Ubuntu 18.04. Pertinent info=20 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


He= re's my guest config file:

$ cat xen-vms/ub1804-dev.hvm
type = =3D "hvm"
name =3D "ub18-dev-work"

# Initial = and max memory allocation (MB)
memory =3D 2048
maxmem =3D 2048
vcpus =3D 1
acpi =3D 1
apic =3D 1
# values: disabled, mixed, exte= rnal, limited
altp2m =3D "mixed"=C2=A0
vif =3D [ 'brid= ge=3Dxenbr0' ]
disk =3D [ 'phy:/dev/ubuntu-vg/xen_ubuntu_dev,xvd= a,w'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,'file:/home/mat= t/iso/ubuntu-18.04.1-desktop-amd64.iso,hdc:cdrom,r' ]
boot =3D '= c' # hard disk (c) / cdrom (d)
console =3D 1
on_poweroff =3D &quo= t;destroy"
on_reboot=C2=A0=C2=A0 =3D "restart"
on_cras= h=C2=A0=C2=A0=C2=A0 =3D "preserve"


Here are the two us= ages of gdbsx (both from Dom0). Note that domain 2 is 64 bit.

# xl l= ist
Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ID=C2=A0=C2=A0 Mem VCPUs=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 State=C2=A0=C2=A0 Time(s)
Domain-0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 30098=C2=A0=C2=A0=C2=A0=C2=A0 8=C2=A0= =C2=A0=C2=A0=C2=A0 r-----=C2=A0=C2=A0=C2=A0 8724.5
ub18-dev-work=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0 2040=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0= =C2=A0=C2=A0=C2=A0 -b----=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 24.9

This is a sanity check....
# gdbsx -c 2 64 0
=3D=3D=3D= > Context for DOMID:2

--> VCPU:0
rip:ffffffff9b1f52e6 rsp:f= fffffff9bc03e10 flags:0000000000000246
rax:ffffffff9b1f4ff0 rbx:00000000= 00000000 rcx:ffffffff9bc6ff60
rdx:0000000000066e16 rsi:ffffffff9bc2ebc8 = rdi:0000000000000000
r08:00000000505563be r09:0000000000000000 r10:00000= 00000000008
r11:0000000000000008 r12:0000000000000000 r13:00000000000000= 00
r14:0000000000000000 r15:0000000000000000 rbp:ffffffff9bc03e10
cs:= 0000000000000010 ds:0000000000000000 fs:0000000000000000 gs:000000000000000= 0

Call Trace:
=C2=A0=C2=A0 [ffffffff9b1f52e6]
=C2=A0=C2=A0 [ff= ffffff9bc03e38]
=C2=A0=C2=A0 [ffffffff9b1f5010]
=C2=A0=C2=A0 [fffffff= f9be85ee0]
=C2=A0=C2=A0 [ffffffff9bc03e48]
=C2=A0=C2=A0 [ffffffff9a83= 94c5]
=C2=A0=C2=A0 [ffffffff9bc03e58]
=C2=A0=C2=A0 [ffffffff9b1f544c]=
=C2=A0=C2=A0 [ffffffff9bc03ea0]
=C2=A0=C2=A0 [ffffffff9a8c3c84]
<= div>=C2=A0=C2=A0 [ffffffff9bf8c920]

This is the ac= tual usage that fails
# gdbsx -a 2 64 3333
Listening on port 33= 33
Remote debugging from host 127.0.0.1
readchar: Got EOF
Detachin= g from guest
Exiting.. Remote side has terminated connection


= And here's the corresponding usage of gdb that led to the failure in gd= bsx (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 targe= t architecture is assumed to be i386:x86-64
gdb> target remote localh= ost:3333
Remote debugging using localhost:3333
warning: No executable= has been specified and target does not support
determining executable a= utomatically.=C2=A0 Try using the "file" command.
Truncated re= gister 26 in remote 'g' packet
gdb> show version
GNU gdb (= Ubuntu 8.2-0ubuntu1~18.04) 8.2
Copyright (C) 2018 Free Software Foundati= on, Inc.
--000000000000a3216a0585e2e40a-- --===============8891381806626683677== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============8891381806626683677==--