[Bug tdep/31038] New: [gdb/tdep] ppc_linux_target_wordsize silently returns wrong result

[Bug tdep/31038] New: [gdb/tdep] ppc_linux_target_wordsize silently returns wrong result

[vries at gcc dot gnu.org]

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

            Bug ID: 31038
           Summary: [gdb/tdep] ppc_linux_target_wordsize silently returns
                    wrong result
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ See also
https://sourceware.org/pipermail/gdb-patches/2023-November/203763.html ]

When doing this:
...
diff --git a/gdb/nat/ppc-linux.c b/gdb/nat/ppc-linux.c
index 0957d1b58a7..100b22a733d 100644
--- a/gdb/nat/ppc-linux.c
+++ b/gdb/nat/ppc-linux.c
@@ -89,6 +89,8 @@ ppc_linux_target_wordsize (int tid)
   msr = (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0);
   if (errno == 0 && ppc64_64bit_inferior_p (msr))
     wordsize = 8;
+  if (errno != 0)
+    error ("Could not get word size");
 #endif

   return wordsize;
...
I run into:
...
FAIL: gdb.base/run-control-while-bg-execution.exp: action1=add: action2=start:
add-inferior
FAIL: gdb.base/run-control-while-bg-execution.exp: action1=add: action2=start:
inferior 2
FAIL: gdb.base/run-control-while-bg-execution.exp: action1=add: action2=run:
add-inferior
FAIL: gdb.base/run-control-while-bg-execution.exp: action1=add: action2=run:
inferior 2
FAIL: gdb.base/run-control-while-bg-execution.exp: action1=add: action2=attach:
add-inferior
FAIL: gdb.base/run-control-while-bg-execution.exp: action1=add: action2=attach:
inferior 2

FAIL: gdb.mi/interrupt-thread-group.exp: add inferior 2 (unexpected output)
FAIL: gdb.mi/interrupt-thread-group.exp: set executable of inferior 2
(unexpected output)
FAIL: gdb.mi/interrupt-thread-group.exp: run inferior 2 (unexpected output)
FAIL: gdb.mi/interrupt-thread-group.exp: inferior i2 stops at
all_threads_started (timeout)
FAIL: gdb.mi/interrupt-thread-group.exp: continue inferior 2 (MI error)
FAIL: gdb.mi/interrupt-thread-group.exp: before interrupting (unexpected
output)
FAIL: gdb.mi/interrupt-thread-group.exp: after interrupting inferior 1
(unexpected output)
FAIL: gdb.mi/interrupt-thread-group.exp: interrupt inferior 2 (unexpected
output)
FAIL: gdb.mi/interrupt-thread-group.exp: inferior 2, interrupt 0 (timeout)
FAIL: gdb.mi/interrupt-thread-group.exp: inferior 2, interrupt 1 (timeout)
FAIL: gdb.mi/interrupt-thread-group.exp: inferior 2, interrupt 2 (timeout)
FAIL: gdb.mi/interrupt-thread-group.exp: inferior 2, interrupt 3 (timeout)
FAIL: gdb.mi/interrupt-thread-group.exp: inferior 2, interrupt 4 (timeout)
FAIL: gdb.mi/interrupt-thread-group.exp: after interrupting inferior 2
(unexpected output)

FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=continue: add-inferior
FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=continue: got MI interrupt output
(unknown output after running)
FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=continue: got -thread-info output
and thread is stopped (timeout)

FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue:
watchpoint:hw: continue
...

I did a similar experiment with an assert instead of an error, and ran into it
in test-case gdb.base/access-mem-running.exp as well.  Not sure yet if that's
due to the difference or because it just doesn't reproduce 100% of the time.

Anyway, this should be addressed.

We shouldn't pretend to have 32-bit process when in fact we have a 64-bit one.

And if the ptrace call fails because the process has exited, an error should be
thrown and handled.

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