* Xen 4.11.1: gdbsx fails
@ 2019-04-05 21:48 ` Matt Leinhos
0 siblings, 0 replies; 6+ messages in thread
From: Matt Leinhos @ 2019-04-05 21:48 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2896 bytes --]
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: 3632 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Xen-devel] Xen 4.11.1: gdbsx fails
@ 2019-04-05 21:48 ` Matt Leinhos
0 siblings, 0 replies; 6+ messages in thread
From: Matt Leinhos @ 2019-04-05 21:48 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2896 bytes --]
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: 3632 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen 4.11.1: gdbsx fails
@ 2019-04-06 21:00 ` Matt Leinhos
0 siblings, 0 replies; 6+ messages in thread
From: Matt Leinhos @ 2019-04-06 21:00 UTC (permalink / raw)
To: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] Xen 4.11.1: gdbsx fails
@ 2019-04-06 21:00 ` Matt Leinhos
0 siblings, 0 replies; 6+ messages in thread
From: Matt Leinhos @ 2019-04-06 21:00 UTC (permalink / raw)
To: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xen 4.11.1: gdbsx fails - stable backport request
@ 2019-04-06 21:07 ` Marek Marczykowski-Górecki
0 siblings, 0 replies; 6+ messages in thread
From: Marek Marczykowski-Górecki @ 2019-04-06 21:07 UTC (permalink / raw)
To: Matt Leinhos; +Cc: xen-devel, Ian Jackson, Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]
On Fri, Apr 05, 2019 at 04:48:16PM -0500, 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.
(...)
> Truncated register 26 in remote 'g' packet
This is already fixed in Xen 4.12:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=0c9821d5c870c35aa38df7bb5e2ff54da2169b5b
I'm proposing this for a backport to stable branches:
0c9821d5c8 tools/gdbsx: fix 'g' packet response for 64bit guests
It may also be reasonable to backport other gdbsx related commits.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] Xen 4.11.1: gdbsx fails - stable backport request
@ 2019-04-06 21:07 ` Marek Marczykowski-Górecki
0 siblings, 0 replies; 6+ messages in thread
From: Marek Marczykowski-Górecki @ 2019-04-06 21:07 UTC (permalink / raw)
To: Matt Leinhos; +Cc: xen-devel, Ian Jackson, Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]
On Fri, Apr 05, 2019 at 04:48:16PM -0500, 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.
(...)
> Truncated register 26 in remote 'g' packet
This is already fixed in Xen 4.12:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=0c9821d5c870c35aa38df7bb5e2ff54da2169b5b
I'm proposing this for a backport to stable branches:
0c9821d5c8 tools/gdbsx: fix 'g' packet response for 64bit guests
It may also be reasonable to backport other gdbsx related commits.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-06 21:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-05 21:48 Xen 4.11.1: gdbsx fails Matt Leinhos
2019-04-05 21:48 ` [Xen-devel] " Matt Leinhos
2019-04-06 21:00 ` Matt Leinhos
2019-04-06 21:00 ` [Xen-devel] " Matt Leinhos
2019-04-06 21:07 ` Xen 4.11.1: gdbsx fails - stable backport request Marek Marczykowski-Górecki
2019-04-06 21:07 ` [Xen-devel] " Marek Marczykowski-Górecki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.