Re: [RFA] Makefile.in, linux.mh: Move Process Record to NATDEPFILES

[Pedro Alves <pedro@codesourcery.com>]

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:

 http://sourceware.org/ml/gdb-patches/2008-06/msg00149.html
 http://sourceware.org/ml/gdb-patches/2008-05/msg00657.html


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.

-- 
Pedro Alves