This is the mail archive of the gdb-patches@sourceware.org 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] Submit process record and replay third time, 3/9


On Thursday 22 January 2009 15:23:48, teawater wrote:

> > 2.1) Related to coupling as well. ?You've added record.c to the list of files that are
> > built on all hosts, but I don't think that record.c is currently buildable on all
> > hosts. ?E.g., you're using sigaction unconditionally. ?I didn't spot any call to
> > a function defined in a *-nat.c file in this patch, but if you have any, you'll need
> > to either remove/rewrite it (ideal, I expect), or build record.c on native
> > linux hosts only.
> 
> OK. I will put it close to linux-record.c. ?Wish it can be back in the future.

I think you're confused.  You've added linux-record.c in configure.tgt.  Those files
will also be built in a cross configuration --- say, if you build a Windows hosted,
linux targeted gdb.  Files that are only to be built when you're building a native
debugger are added to NATDEPFILES in the various .mt files under src/gdb/config/.
Now, if you added record.o to the relevant linux NATDEPFILES, you'd still be breaking
all other hosts, because you have references to functions and variables defined in
record.c throughout gdb's core.  Since other hosts wouldn't include the record.o
object, they'd fail to link.

Here's what I propose you try as first step: remove all references to record.o
from Makefile.in and configure.tgt.  Try building.  You'll get link errors.  Now,
come up with interfaces between the core and record.c that would preserve all
functionality if record.o isn't included in the link; but that will still link
a gdb executable, if record.o isn't linked in.

-- 
Pedro Alves


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