public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug cli/27838] New: set architecture x86_84 on a 32-bit process
@ 2021-05-10  9:57 bp at alien8 dot de
  2021-05-10  9:58 ` [Bug cli/27838] " bp at alien8 dot de
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: bp at alien8 dot de @ 2021-05-10  9:57 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

            Bug ID: 27838
           Summary: set architecture x86_84 on a 32-bit process
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: cli
          Assignee: unassigned at sourceware dot org
          Reporter: bp at alien8 dot de
  Target Milestone: ---

Setting the target architecture to x86_64 on a 32-bit process after it has
switched to long mode, fails. Exact steps to reproduce:

wget
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/plain/tools/testing/selftests/x86/test_syscall_vdso.c
wget
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/plain/tools/testing/selftests/x86/helpers.h
wget
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/plain/tools/testing/selftests/x86/thunks_32.S

gcc -m32 -o test_syscall_vdso_32 -O2 -g -std=gnu99 -pthread -Wall -no-pie
-DCAN_BUILD_32 -DCAN_BUILD_64 test_syscall_vdso.c helpers.h thunks_32.S -lrt
-ldl -lm

~/dev/binutils/build/gdb/gdb test_syscall_vdso_32

...

Reading symbols from test_syscall_vdso_32...
(gdb) break call64_from_32
Breakpoint 1 at 0x8049b08: file thunks_32.S, line 19.

(gdb) r
Starting program: /tmp/gdb/test_syscall_vdso_32
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[WARN]  AT_SYSINFO not supplied
[RUN]   Executing 6-argument 32-bit syscall via INT 80

Breakpoint 1, Python Exception <type 'exceptions.NameError'>: Installation
error: gdb._execute_unwinders function is missing
call64_from_32 () at thunks_32.S:19
19              mov     4(%esp), %eax
(gdb) stepi
22              push    %ecx
(gdb)
call64_from_32 () at thunks_32.S:23
23              push    %edx
(gdb)
call64_from_32 () at thunks_32.S:24
24              push    %esi
(gdb)
call64_from_32 () at thunks_32.S:25
25              push    %edi
(gdb)
call64_from_32 () at thunks_32.S:28

<--- this will switch tracee to long mode:

28              jmp     $0x33,$1f
(gdb) stepi
32              call    *%rax
(gdb) info registers
eax            0x80492e8           134517480
ecx            0x1                 1
edx            0x804c160           134529376
ebx            0x804c000           134529024
esp            0xffffd5ac          0xffffd5ac
ebp            0x804c000           0x804c000
esi            0x0                 0
edi            0x0                 0
eip            0x8049b17           0x8049b17 <call64_from_32+15>
eflags         0x292               [ AF SF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x2b                43
es             0x2b                43
fs             0x0                 0
gs             0x63                99

<--- but those registers are still the i386 set. Let's try to tell gdb the
architecture of the tracee:

(gdb) set architecture x86_64
Undefined item: "x86_64".
(gdb) set architecture i386:x86_64
Undefined item: "i386:x86_64".
(gdb) set architecture i386 x86_64
Junk after item "i386": x86_64
(gdb) set architecture i386:x86_64
Undefined item: "i386:x86_64".
(gdb) set architecture x86_64
Undefined item: "x86_64".
(gdb) set architecture i386

The target architecture is set to "i386".
(gdb) info registers
eax            0x80492e8           134517480
ecx            0x1                 1
edx            0x804c160           134529376
ebx            0x804c000           134529024
esp            0xffffd5ac          0xffffd5ac
ebp            0x804c000           0x804c000
esi            0x0                 0
edi            0x0                 0
eip            0x8049b17           0x8049b17 <call64_from_32+15>
eflags         0x292               [ AF SF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x2b                43
es             0x2b                43
fs             0x0                 0
gs             0x63                99
(gdb) set architecture x86_64
Undefined item: "x86_64".

Maybe I'm doing it wrong...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
@ 2021-05-10  9:58 ` bp at alien8 dot de
  2021-05-10 10:37 ` vries at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: bp at alien8 dot de @ 2021-05-10  9:58 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

Borislav Petkov <bp at alien8 dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luto at kernel dot org,
                   |                            |matz at suse dot de,
                   |                            |vries at gcc dot gnu.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
  2021-05-10  9:58 ` [Bug cli/27838] " bp at alien8 dot de
@ 2021-05-10 10:37 ` vries at gcc dot gnu.org
  2021-05-10 10:48 ` vries at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-05-10 10:37 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
...
(gdb) set arch
Requires an argument. Valid arguments are i386, i386:x86-64, i386:x64-32,
i8086, i386:intel, i386:x86-64:intel, i386:x64-32:intel, rs6000:6000,
rs6000:rs1, rs6000:rsc, rs6000:rs2, powerpc:common64, powerpc:common,
powerpc:603, powerpc:EC603e, powerpc:604, powerpc:403, powerpc:601,
powerpc:620, powerpc:630, powerpc:a35, powerpc:rs64ii, powerpc:rs64iii,
powerpc:7400, powerpc:e500, powerpc:e500mc, powerpc:e500mc64, powerpc:MPC8XX,
powerpc:750, powerpc:titan, powerpc:vle, powerpc:e5500, powerpc:e6500,
s390:64-bit, s390:31-bit, arm, armv2, armv2a, armv3, armv3m, armv4, armv4t,
armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, armv5tej, armv6,
armv6kz, armv6t2, armv6k, armv7, armv6-m, armv6s-m, armv7e-m, armv8-a, armv8-r,
armv8-m.base, armv8-m.main, armv8.1-m.main, arm_any, aarch64, aarch64:ilp32,
aarch64:armv8-r, m68k, m68k:68000, m68k:68008, m68k:68010, m68k:68020,
m68k:68030, m68k:68040, m68k:68060, m68k:cpu32, m68k:fido, m68k:isa-a:nodiv,
m68k:isa-a, m68k:isa-a:mac, m68k:isa-a:emac, m68k:isa-aplus,
m68k:isa-aplus:mac, m68k:isa-aplus:emac, m68k:isa-b:nousp,
m68k:isa-b:nousp:mac, m68k:isa-b:nousp:emac, m68k:isa-b, m68k:isa-b:mac,
m68k:isa-b:emac, m68k:isa-b:float, m68k:isa-b:float:mac, m68k:isa-b:float:emac,
m68k:isa-c, m68k:isa-c:mac, m68k:isa-c:emac, m68k:isa-c:nodiv,
m68k:isa-c:nodiv:mac, m68k:isa-c:nodiv:emac, m68k:5200, m68k:5206e, m68k:5307,
m68k:5407, m68k:528x, m68k:521x, m68k:5249, m68k:547x, m68k:548x, m68k:cfv4e,
ia64-elf64, ia64-elf32, riscv, riscv:rv64, riscv:rv32, auto.
...


> ...
> (gdb) set architecture i386:x86_64
> Undefined item: "i386:x86_64".
> ...

Maybe try i386:x86-64 ?  So, dash instead of underscore?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
  2021-05-10  9:58 ` [Bug cli/27838] " bp at alien8 dot de
  2021-05-10 10:37 ` vries at gcc dot gnu.org
@ 2021-05-10 10:48 ` vries at gcc dot gnu.org
  2021-05-10 11:09 ` vries at gcc dot gnu.org
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-05-10 10:48 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, at least the docs ( https://sourceware.org/gdb/onlinedocs/gdb/Targets.html
) need to be improved, there's no mention how to find out what are valid
arguments for set arch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
                   ` (2 preceding siblings ...)
  2021-05-10 10:48 ` vries at gcc dot gnu.org
@ 2021-05-10 11:09 ` vries at gcc dot gnu.org
  2021-05-10 12:21 ` vries at gcc dot gnu.org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-05-10 11:09 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
OK, I tried the example, and got:
...
(gdb) 
call64_from_32 () at thunks_32.S:28
28              jmp     $0x33,$1f
(gdb) set architecture i386:x86-64
warning: Selected architecture i386:x86-64 is not compatible with reported
target architecture i386
Architecture `i386:x86-64' not recognized.
The target architecture is set to "auto" (currently "i386").
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
                   ` (3 preceding siblings ...)
  2021-05-10 11:09 ` vries at gcc dot gnu.org
@ 2021-05-10 12:21 ` vries at gcc dot gnu.org
  2021-05-10 12:24 ` matz at suse dot de
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-05-10 12:21 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> Architecture `i386:x86-64' not recognized.

OK, so this is down to this check in i386_validate_tdesc_p:
...
      for (i = 0; i < tdep->num_ymm_regs; i++)
        valid_p &= tdesc_numbered_register (feature_avx, tdesc_data,
                                            tdep->ymm0h_regnum + i,
                                            tdep->ymmh_register_names[i]);
    }
...

We have these two which match:
...
(gdb) p tdep->num_ymm_regs
$21 = 16
(gdb) p tdep->ymmh_register_names
$22 = (const char * const *) 0xe65fe0 <amd64_ymmh_names>
...
but the feature_avx ( org.gnu.gdb.i386.avx ) just contains 8 registers, so
tdesc_numbered_register returns 0 for regs 8-15.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
                   ` (4 preceding siblings ...)
  2021-05-10 12:21 ` vries at gcc dot gnu.org
@ 2021-05-10 12:24 ` matz at suse dot de
  2021-05-10 12:26 ` matz at suse dot de
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: matz at suse dot de @ 2021-05-10 12:24 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #5 from Michael Matz <matz at suse dot de> ---
This once worked in older gdbs, at least when the target was a qemu-stub of a
full system emulation, you could freely roam the various modes the processor
has (from 16 bit real mode during early boot loader, to 32bit flat to 64bit
flat memory mode), via architectures 'i8086', 'i386' and 'i386:x86-64'. 
(Ideally gdb would have found out the current CPU mode automatically, but
missing that manually setting the arch was somewhat okay).

It seems we now get the same warning message and misbehaviour also with that
target.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
                   ` (5 preceding siblings ...)
  2021-05-10 12:24 ` matz at suse dot de
@ 2021-05-10 12:26 ` matz at suse dot de
  2021-05-10 13:01 ` vries at gcc dot gnu.org
  2021-05-10 13:07 ` bp at alien8 dot de
  8 siblings, 0 replies; 10+ messages in thread
From: matz at suse dot de @ 2021-05-10 12:26 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #6 from Michael Matz <matz at suse dot de> ---
(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #3)
> > Architecture `i386:x86-64' not recognized.
> 
> OK, so this is down to this check in i386_validate_tdesc_p:
> ...
>       for (i = 0; i < tdep->num_ymm_regs; i++)
>         valid_p &= tdesc_numbered_register (feature_avx, tdesc_data,
>                                             tdep->ymm0h_regnum + i,
>                                             tdep->ymmh_register_names[i]);
>     }
> ...
> 
> We have these two which match:
> ...
> (gdb) p tdep->num_ymm_regs
> $21 = 16
> (gdb) p tdep->ymmh_register_names
> $22 = (const char * const *) 0xe65fe0 <amd64_ymmh_names>
> ...
> but the feature_avx ( org.gnu.gdb.i386.avx ) just contains 8 registers, so
> tdesc_numbered_register returns 0 for regs 8-15.

That makes sense.  In 32bit mode only the low 8 registers are accessible.
tdep->num_ymm_regs should probably reflect that, I guess.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
                   ` (6 preceding siblings ...)
  2021-05-10 12:26 ` matz at suse dot de
@ 2021-05-10 13:01 ` vries at gcc dot gnu.org
  2021-05-10 13:07 ` bp at alien8 dot de
  8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-05-10 13:01 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
I used this hack to get the arch switch approved:
...
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 50fd2767a18..4c0177847af 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -8174,10 +8174,16 @@ i386_floatformat_for_type (struct gdbarch *gdbarch,
   return default_floatformat_for_type (gdbarch, name, len);
 }

+static int cnt_calls = 0;
+
 static int
 i386_validate_tdesc_p (struct gdbarch_tdep *tdep,
                       struct tdesc_arch_data *tdesc_data)
 {
+  fprintf (stderr, "CNT_CALLS: %d\n", cnt_calls);
+  if (cnt_calls == 2)
+    return 1;
+  cnt_calls++;
   const struct target_desc *tdesc = tdep->tdesc;
   const struct tdesc_feature *feature_core;

...

But results aren't that great:
...
$ gdb -q -batch test_syscall_vdso_32 -ex "break call64_from_32" -ex run -ex
stepi -ex stepi -ex stepi -ex stepi -ex stepi -ex stepi -ex "set arch
i386:x86-64" -ex "info registers"
CNT_CALLS: 0
Breakpoint 1 at 0x8048ed5: file thunks_32.S, line 19.
CNT_CALLS: 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[RUN]   Executing 6-argument 32-bit syscall via VDSO

Breakpoint 1, call64_from_32 () at thunks_32.S:19
19              mov     4(%esp), %eax
22              push    %ecx
call64_from_32 () at thunks_32.S:23
23              push    %edx
call64_from_32 () at thunks_32.S:24
24              push    %esi
call64_from_32 () at thunks_32.S:25
25              push    %edi
call64_from_32 () at thunks_32.S:28
28              jmp     $0x33,$1f
32              call    *%rax
warning: Selected architecture i386:x86-64 is not compatible with reported
target architecture i386
CNT_CALLS: 2
The target architecture is set to "i386:x86-64".
eax            <unavailable>
ecx            <unavailable>
edx            <unavailable>
ebx            <unavailable>
esp            <unavailable>
ebp            <unavailable>
esi            <unavailable>
edi            <unavailable>
eip            <unavailable>
eflags         <unavailable>
cs             <unavailable>
ss             <unavailable>
ds             <unavailable>
es             <unavailable>
fs             <unavailable>
gs             <unavailable>
st0            <unavailable>
st1            <unavailable>
st2            <unavailable>
st3            <unavailable>
st4            <unavailable>
st5            <unavailable>
st6            <unavailable>
st7            <unavailable>
fctrl          <unavailable>
fstat          <unavailable>
ftag           <unavailable>
fiseg          <unavailable>
fioff          <unavailable>
foseg          <unavailable>
fooff          <unavailable>
fop            <unavailable>
xmm0           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm1           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm2           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm3           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm4           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm5           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm6           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
xmm7           {v4_float = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_double = {<unavailable>, <unavailable>}, v16_int8 =
{<unavailable> <repeats 16 times>}, v8_int16 = {<unavailable>, <unavailable>,
<unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v4_int32 = {<unavailable>, <unavailable>, <unavailable>,
<unavailable>}, v2_int64 = {<unavailable>, <unavailable>}, uint128 =
<unavailable>}
mxcsr          <unavailable>
orig_eax       <unavailable>
ymm0h          <unavailable>
ymm1h          <unavailable>
ymm2h          <unavailable>
ymm3h          <unavailable>
ymm4h          <unavailable>
ymm5h          <unavailable>
ymm6h          <unavailable>
ymm7h          <unavailable>
bnd0raw        {lbound = <unavailable>, ubound_raw = <unavailable>}
bnd1raw        {lbound = <unavailable>, ubound_raw = <unavailable>}
bnd2raw        {lbound = <unavailable>, ubound_raw = <unavailable>}
bnd3raw        {lbound = <unavailable>, ubound_raw = <unavailable>}
bndcfgu        {raw = <unavailable>, config = {base = <unavailable>, reserved =
<unavailable>, preserved = <unavailable>, enabled = <unavailable>}}
bndstatus      {raw = <unavailable>, status = {bde = <unavailable>, error =
<unavailable>}}
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug cli/27838] set architecture x86_84 on a 32-bit process
  2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
                   ` (7 preceding siblings ...)
  2021-05-10 13:01 ` vries at gcc dot gnu.org
@ 2021-05-10 13:07 ` bp at alien8 dot de
  8 siblings, 0 replies; 10+ messages in thread
From: bp at alien8 dot de @ 2021-05-10 13:07 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=27838

--- Comment #8 from Borislav Petkov <bp at alien8 dot de> ---
... and the r8-r15 are not shown either. Can the ptrace API even fetch current
registers? Maybe set arch ...x86-64 should fetch all regs too...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-05-10 13:07 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-10  9:57 [Bug cli/27838] New: set architecture x86_84 on a 32-bit process bp at alien8 dot de
2021-05-10  9:58 ` [Bug cli/27838] " bp at alien8 dot de
2021-05-10 10:37 ` vries at gcc dot gnu.org
2021-05-10 10:48 ` vries at gcc dot gnu.org
2021-05-10 11:09 ` vries at gcc dot gnu.org
2021-05-10 12:21 ` vries at gcc dot gnu.org
2021-05-10 12:24 ` matz at suse dot de
2021-05-10 12:26 ` matz at suse dot de
2021-05-10 13:01 ` vries at gcc dot gnu.org
2021-05-10 13:07 ` bp at alien8 dot de

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).