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]

Re: How to implement gcore on pa-hpux ?


Joel Brobecker wrote:
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.


That's almost the approach I took. The problem with the above
is that you end up rewriting a bunch of code that could have
been reused (namely the code that adds the "gcore" command,
and the part of gcore_command that deals with arguments).

If you really want to know, I did

gcore_command (...)
{
  [part that deals with arguments]

#ifdef HAVE_TTRACE
  dump_core_file (...);
  return;
#endif

  [rest of the regular gcore_command]
}

OK, well, without looking at your code I don't know if this is applicable, but I did write the gcore code so as to use callbacks. It was intended to be extendable, so that whatever needed to be done per-section(segment) could be done by the callbacks, which you could supply.

The callbacks supplied are for elf, for instance, which
is the only object format that I directly addressed, but
I would hope that callbacks for other formats could be
made to fit.  I was intending, for instance, to implement
a callback for remote targets that would simply read the
memory from the remote-writeable sections and copy it into
a file.

Can this not be made to work for you?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]