Vasily Kolobkov <[email protected]> writes: > On Thu, Mar 10, 2016 at 01:08:36AM +0100, Jeremie Courreges-Anglas wrote: >> Philip Guenther <[email protected]> writes: >> >> > Broadening to ports@ >> > >> > With respect to this question in my original note: >> >> Or maybe new gdb has some way to have ptid_get_pid() return the >> >> per-thread value? >> > >> > the answer appears to be "nope, no new magic in gdb for that". >> >> Makes sense, I only tested with an old gdb (7.9.1) so far but will take >> a look at -current soon. >> >> Pascal, any objection? >> >> > >> > Philip >> > >> > ---------- Forwarded message ---------- >> > Date: Sun, 19 Apr 2015 16:18:07 -0700 >> > From: Philip Guenther <[email protected]> >> > To: Pascal Stumpf <[email protected]> >> > Cc: Mark Kettenis <[email protected]> >> > Subject: ports gdb thread handling... >> > >> > >> > Looks like the gdb in ports needs patching to try ptid_get_lwp() before >> > ptid_get_pid() when fetching/setting registers. For example, diff below >> > fixes this for amd64. Without this it always reports the original >> > thread's registers (and thus the same backtrace), but with it I can get >> > distinct backtraces like: >> > ... > > Being haunted by seemingly the same issue, the 7.11 version did help in > my case and shows correct call stacks, while 7.10.1 did not. All amd64.
Heh, upstream introduced new magic, get_ptrace_pid, and jhb@freebsd started using it in gdb/amd64bsd-nat.c and gdb/i386bsd-nat.c. Other archs were not touched. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
