From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Eli Zaretskii Cc: kevinb@cygnus.com, kettenis@wins.uva.nl, gdb@sources.redhat.com Subject: Re: [RFC] Unified watchpoints for x86 platforms Date: Thu, 15 Feb 2001 14:46:00 -0000 Message-id: <5melwzd0qr.fsf@jtc.redback.com> 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> X-SW-Source: 2001-02/msg00193.html >>>>> "Eli" == Eli Zaretskii writes: >> > Is there any particular reason why you need the PID argument? AFAICS >> > it will always be equal to INFERIOR_PID, so I think we can do without >> > it. This is also true for the other i386_hwbp_* functions you're >> > proposing. >> >> I think it'd be better to not rely on ``inferior_pid''. I would >> rather see the explicitly passed. There will come a day when GDB >> is able to debug more than one process at a time and to perpetuate >> reliance on inferior pid would be short sighted. Eli> I have two opposite opinions here. We need to resolve this somehow. 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. It is not clear to me that adding such an argument "because it will be needed" is correct, considering that the design has not yet started. The truth is we don't know "what" will be needed, so we'll have to revisit this function (among many others) down the line anyway. --jtc -- J.T. Conklin RedBack Networks