From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: [RFC] Unified watchpoints for x86 platforms Date: Fri, 16 Feb 2001 00:45:00 -0000 Message-id: <1010216084509.ZM10601@ocotillo.lan> References: <200009070855.EAA00749@albacore> <200009071500.LAA07756@indy.delorie.com> <200009081529.e88FTjx15960@debye.wins.uva.nl> <200102101533.KAA10417@indy.delorie.com> <200102151146.NAA28431@is.elta.co.il> <1010215184135.ZM8866@ocotillo.lan> <200102152125.QAA15548@indy.delorie.com> <5melwzd0qr.fsf@jtc.redback.com> <200102160729.CAA01185@indy.delorie.com> X-SW-Source: 2001-02/msg00205.html On Feb 16, 2:29am, Eli Zaretskii wrote: > > We're going to need to pass a PID, or perhaps some new representation > > of a execution context, to a lot of code functions that don't allready > > have such an argument. > > Sorry, I'm not sure I'm following: why do you envision we'll need to > pass the PID to functions that don't receive it today? What > function(s) did you have in mind? The idea (I think) is to make most uses of ``inferior_pid'' go away. In its place will be occurrences of PIDGET (ptid) (or something along these lines) where ptid is passed from somewhere else. As a result, it will very likely become necessary to pass the execution context (or perhaps an identifier representing the execution context) as a parameter or perhaps as a member of some larger structure. See http://sources.redhat.com/ml/gdb-patches/2000-10/msg00014.html This patch doesn't address the elimination of inferior_pid, but it does take a first step towards providing a more robust execution context identifier in the sense that it is now possible to encode a process id, thread id, and lightweight process id in one of these identifiers. At the moment, we use a single int to encode the following: - a process id (alone) - a process id and a thread id - a process id and an lwp id IIRC, there are also times where the int in question ends up containing just the thread id or just the lwp id. Kevin