This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Process ID munging
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: Process ID munging
- From: David Taylor <taylor at cygnus dot com>
- Date: Wed, 26 Apr 2000 14:17:05 -0400
- cc: Mark Kettenis <kettenis at wins dot uva dot nl>, msnyder at cygnus dot com, gdb at sourceware dot cygnus dot com
Date: Wed, 26 Apr 2000 15:51:00 +1000
From: Andrew Cagney <ac131313@cygnus.com>
[...]
The short term bandaid most likely involves changing that PID to a
LONGEST (or a typedef LONGEST ...). Longer term, it is going to need a
more radical treatment.
Instead of the current integer, a thread object that has bound to it
things like its architecture, its symbol information, its address map,
its target interface and even its cached register/memory information.
Implementing it involves some careful thought and a serious amount of
strategizing (.... :-).
How about something like...
struct process
{
pid_t p_pid; /* make it an int if pid_t causes too many problems */
int p_tid;
... other fields to be determined later ...
}
struct process *current_process;
#define inferior_pid current_process->p_pid
Wouldn't that get us more than 90% there?
Yes, I realize that there are still issues. But, it seems that if you
did something like this that most files would require no editing...
Initially current_process could be allocated once at startup; later it
could be allocated / freed when the 'process' is 'created' / 'killed'.