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

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> 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 don't propose breaking it, simply setting it aside for now.
My suggestion also does not prevent testing it - eg. with a
remote target and i386-linux host.

Anyway, right now I can see only two choices -- this, or
reverting the prec-save change.  I'm open to whichever one
the group prefers.