This is the mail archive of the 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: [RFA], Move Process Record to NATDEPFILES

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

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 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.

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