This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Makefile.in, linux.mh: Move Process Record to NATDEPFILES
On Sunday 25 October 2009 01:30:57, Michael Snyder wrote:
> 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.
There wasn't that much discussion:
I major point I was trying to put across, and that I could have
been a bit more explicit is that, being able to be used
transparently of whatever's the process_stratum target
beneath (as opposed to only the native child target)
means "precord should be host independent".
> 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.
Huh. So? Does that mean we should break it and make it
impossible to test?
> 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?
No. Sorry, I could have been clearer explaning the
objection. Take for example, moxie precord
support (--target=moxie-elf): this AFAICS, works with
"target sim" --- hence _host independent_.
Making record.o only link on gdbs that currently link
against gcore.o would make that support _host dependent_, which
is obviously wrong. Why shouldn't e.g, a i686-mingw32 x moxie-elf
gdb be able to support reverse moxie debugging? Moxie here
is just an example, other target sim supported archs could
gain precord support.
> >> 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).
No, sorry. As I said, precord support should not be host
dependent, as it was up until a few days ago.
A simpler fix, would be to go the other direction. That
of making gdb always link with gcore.o and corelow.o.