This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Makefile.in, linux.mh: Move Process Record to NATDEPFILES
- From: Michael Snyder <msnyder at vmware dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Sat, 24 Oct 2009 18:30:57 -0700
- Subject: Re: [RFA] Makefile.in, linux.mh: Move Process Record to NATDEPFILES
- References: <4AE1CF46.7030106@vmware.com> <200910231711.48441.pedro@codesourcery.com>
Pedro Alves wrote:
On Friday 23 October 2009 16:44:06, Michael Snyder wrote:
Hey folks, we ran into a bunch of build problems because record.c
was being compiled in a lot of builds where it wasn't needed (or
tested).
This change will make record.c be like gcore.c, in that it is only
built if the target config files explicitly call for it.
(You mean the host config file.)
No. We had designed record_stratum so that it could be used
transparently of whatever's the process_stratum target beneath, which
allows precord to work against remote (gdbserver) and sim, e.g.,
moxie precord support.
Hmmm, ok -- I must not have followed that discussion closely.
I don't think the fact that precord can work against whatever
target is beneath it has been widely advertised yet. It certainly
hasn't been widely tested, eg. against remote.
I appreciate the desire, but is it ready for prime time?
Perhaps, as a compromise, we could link record.o against all
gdbs that currently link against gcore.o? Which would include
most linuxen, many freebsd, and both i386 and sparc solaris?
For this patch, I've only included record.c for i386-linux.
We can add amd64-linux in a separate patch if we decide it is
ready.
I should have gone on to say, and then add more hosts
as and when they are ready (assuming they also support gcore).