This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Jan 04, 2006 at 09:40:09PM +0400, Joel Brobecker wrote:
So I created a new function in infttrace.c. In order to avoid re-writing the part of gcore.c that add the command, and handles the arguments of this command, I simply hooked the new infttrace directly into the gcore code. A bit crude, but it works and it's pretty localized.
For the FSF tree, I'd like to implement this a little better, and it seems to me that the core part of this command, the part that actually creates the core file, should be a method of some vector. But which vector?
The way the gcore command is currently written, it seems that it would make sense for it to be part of the target vector. No?
However, in the case of HP/UX, there is a slight complication, because the method is only good in the native case...
If you really mean target vector, then this isn't a complication at all. The native case should have its own target vector already, in inf-ttrace.c (note the dash in modern sources). Ideally remote targets could gcore; but there's been no interest in implementing that so far, so it's not worth concerning ourselves with until someone wants to work on it.
The "gcore" command is actually defined in gcore.c. If someone (hpux) wanted to define it differently, it should be as simple as linking in your own (eg.) hpux-gcore.c module, *instead of* the generic gcore.c module.
Current targets that implement gcore in the generic way do so by adding gcore.o to the NATDEPFILES.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |