This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/gdbserver/LynxOS]: Incomplete thread list after --attach
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 01 Oct 2013 11:16:51 +0100
- Subject: Re: [RFA/gdbserver/LynxOS]: Incomplete thread list after --attach
- Authentication-results: sourceware.org; auth=none
- References: <1380621039-25204-1-git-send-email-brobecker at adacore dot com> <524A9C9E dot 2040407 at redhat dot com> <20131001100200 dot GA2840 at adacore dot com>
On 10/01/2013 11:02 AM, Joel Brobecker wrote:
>>> Unfortunately, as the added comments hints, there appears to be
>>> no way of getting the list of threads via ptrace, other than by
>>> spawning the "ps" command, and parsing its output. Not great,
>>> but it appears to be the best we can do. This method was actually
>>> inspired by looking at old code which did exactly that.
>>
>> Huh. I didn't really look at the patch yet, but, then, how
>> does "ps" manage to work? If you strace "ps", what system calls
>> is it using? I'd imagine if not ptrace, then it would be reading
>> /proc or some such?
>
> I can look. But what strongly detered me from doing that is the fact
> that it'd be starting to use unpublished interfaces.
Well, how are you sure they're unpublished, if you don't know
at least approximately which interfaces it's using? (reading /proc,
using ptrace+peeking at program memory, etc.) ;-) I've really no
clue on the ABI garantees copying newer/older "ps" to an older/newer
system would have, but I'd expect it to have some.
BTW, was that "old code" the old native gdb port?
> Running "ps" isn't pretty, but I can hope it'll keep working across versions of
> Lynx (we tested against Lynx 178 and 5.x, knowing that this has worked
> with 4.x as well).
It's hard to believe such a basic feature would go missing from
a public debug API :-(, but I can't say I really object to the patch.
If it works for you...
> +/* Assuming we've just attached to a running inferior whose pid is PID,
> + add all threads runnnig in that process. */
"running".
--
Pedro Alves