Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 510036 Details for
Bug 562128
>=sys-devel/gdb-7.10 hangs/spins-on-cpu when debugging any program on Alpha
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
alpha-tdep-fix.patch
alpha-tdep-fix.patch (text/plain), 4.33 KB, created by
Tobias Klausmann (RETIRED)
on 2017-12-14 16:06:42 UTC
(
hide
)
Description:
alpha-tdep-fix.patch
Filename:
MIME Type:
Creator:
Tobias Klausmann (RETIRED)
Created:
2017-12-14 16:06:42 UTC
Size:
4.33 KB
patch
obsolete
>--- a/gdb/alpha-tdep.c 2017-12-14 15:56:48.955960647 +0100 >+++ b/gdb/alpha-tdep.c 2017-12-14 15:56:33.751806965 +0100 >@@ -766,10 +766,8 @@ > the sequence. */ > > static VEC (CORE_ADDR) * >-alpha_deal_with_atomic_sequence (struct regcache *regcache) >+alpha_deal_with_atomic_sequence (struct gdbarch *gdbarch, CORE_ADDR pc) > { >- struct gdbarch *gdbarch = get_regcache_arch (regcache); >- CORE_ADDR pc = regcache_read_pc (regcache); > CORE_ADDR breaks[2] = {-1, -1}; > CORE_ADDR loc = pc; > CORE_ADDR closing_insn; /* Instruction that closes the atomic sequence. */ >@@ -1721,12 +1719,17 @@ > alpha_software_single_step (struct regcache *regcache) > { > struct gdbarch *gdbarch = get_regcache_arch (regcache); >- CORE_ADDR pc; >- VEC (CORE_ADDR) *next_pcs = NULL; >+ CORE_ADDR pc, next_pc; >+ VEC (CORE_ADDR) *next_pcs; > > pc = regcache_read_pc (regcache); >+ next_pcs = alpha_deal_with_atomic_sequence (gdbarch, pc); >+ if (next_pcs != NULL) >+ return next_pcs; >+ >+ next_pc = alpha_next_pc (regcache, pc); > >- VEC_safe_push (CORE_ADDR, next_pcs, alpha_next_pc (regcache, pc)); >+ VEC_safe_push (CORE_ADDR, next_pcs, next_pc); > return next_pcs; > } > >@@ -1826,7 +1829,7 @@ > set_gdbarch_cannot_step_breakpoint (gdbarch, 1); > > /* Handles single stepping of atomic sequences. */ >- set_gdbarch_software_single_step (gdbarch, alpha_deal_with_atomic_sequence); >+ set_gdbarch_software_single_step (gdbarch, alpha_software_single_step); > > /* Hook in ABI-specific overrides, if they have been registered. */ > gdbarch_init_osabi (info, gdbarch); >diff --git a/gdb/nat/linux-ptrace.h b/gdb/nat/linux-ptrace.h >index c5b0f14..8354a4d 100644 >--- a/gdb/nat/linux-ptrace.h >+++ b/gdb/nat/linux-ptrace.h >@@ -88,6 +88,57 @@ struct buffer; > #define __WALL 0x40000000 /* Wait for any child. */ > #endif > >+/* True if whether a breakpoint/watchpoint triggered can be determined >+ from the si_code of SIGTRAP's siginfo_t (TRAP_BRKPT/TRAP_HWBKPT). >+ That is, if the kernel can tell us whether the thread executed a >+ software breakpoint, we trust it. The kernel will be determining >+ that from the hardware (e.g., from which exception was raised in >+ the CPU). Relying on whether a breakpoint is planted in memory at >+ the time the SIGTRAP is processed to determine whether the thread >+ stopped for a software breakpoint can be too late. E.g., the >+ breakpoint could have been removed since. Or the thread could have >+ stepped an instruction the size of a breakpoint instruction, and >+ before the stop is processed a breakpoint is inserted at its >+ address. Getting these wrong is disastrous on decr_pc_after_break >+ architectures. The moribund location mechanism helps with that >+ somewhat but it is an heuristic, and can well fail. Getting that >+ information out of the kernel and ultimately out of the CPU is the >+ way to go. That said, some architecture may get the si_code wrong, >+ and as such we're leaving fallback code in place. We'll remove >+ this after a while if no problem is reported. */ >+#define USE_SIGTRAP_SIGINFO 1 >+ >+/* The x86 kernel gets some of the si_code values backwards, like >+ this: >+ >+ | what | si_code | >+ |------------------------------------------+------------| >+ | software breakpoints (int3) | SI_KERNEL | >+ | single-steps | TRAP_TRACE | >+ | single-stepping a syscall | TRAP_BRKPT | >+ | user sent SIGTRAP | 0 | >+ | exec SIGTRAP (when no PTRACE_EVENT_EXEC) | 0 | >+ | hardware breakpoints/watchpoints | TRAP_HWBPT | >+ >+ That is, it reports SI_KERNEL for software breakpoints (and only >+ for those), and TRAP_BRKPT for single-stepping a syscall... If the >+ kernel is ever fixed, we'll just have to detect it like we detect >+ optional ptrace features: by forking and debugging ourselves, >+ running to a breakpoint and checking what comes out of >+ siginfo->si_code. >+ >+ The generic Linux target code should use GDB_ARCH_TRAP_BRKPT >+ instead of TRAP_BRKPT to abstract out this x86 peculiarity. */ >+#if defined __i386__ || defined __x86_64__ >+# define GDB_ARCH_TRAP_BRKPT SI_KERNEL >+#else >+# define GDB_ARCH_TRAP_BRKPT TRAP_BRKPT >+#endif >+ >+#ifndef TRAP_HWBKPT >+# define TRAP_HWBKPT 4 >+#endif >+ > extern void linux_ptrace_attach_fail_reason (pid_t pid, struct buffer *buffer);
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 562128
: 510036