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

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

[Michael Snyder]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

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.

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.

Michael


[-- Attachment #2: natdep.txt --]
[-- Type: text/plain, Size: 1716 bytes --]

2009-10-23  Michael Snyder  <msnyder@vmware.com>

	* Makefile.in (COMMON_OBS): Remove record.o.
	(ALL_TARGET_OBS): Remove linux-record.o.
	config/i386/linux.h (NATDEPFILES): Add record.o, linux-record.o.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.1103
diff -u -p -w -b -r1.1103 Makefile.in
--- Makefile.in	21 Oct 2009 14:14:56 -0000	1.1103
+++ Makefile.in	23 Oct 2009 15:45:31 -0000
@@ -531,8 +531,7 @@ ALL_TARGET_OBS = \
 	xcoffread.o \
 	symfile-mem.o \
 	corelow.o \
-	windows-tdep.o \
-	linux-record.o
+	windows-tdep.o
 
 # Host-dependent makefile fragment comes in here.
 @host_makefile_frag@
@@ -834,7 +833,7 @@ COMMON_OBS = $(DEPFILES) $(CONFIG_OBS) $
 	solib.o solib-null.o \
 	prologue-value.o memory-map.o xml-support.o xml-syscall.o \
 	target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o \
-	inferior.o osdata.o gdb_usleep.o record.o \
+	inferior.o osdata.o gdb_usleep.o \
 	jit.o progspace.o
 
 # Definitions for the syscall's XML files and dir
Index: config/i386/linux.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/linux.mh,v
retrieving revision 1.21
diff -u -p -w -b -r1.21 linux.mh
--- config/i386/linux.mh	14 Aug 2007 12:51:59 -0000	1.21
+++ config/i386/linux.mh	23 Oct 2009 15:45:31 -0000
@@ -4,7 +4,7 @@ NAT_FILE= nm-linux.h
 NATDEPFILES= inf-ptrace.o fork-child.o \
 	i386-nat.o i386-linux-nat.o \
 	proc-service.o linux-thread-db.o gcore.o \
-	linux-nat.o linux-fork.o
+	linux-nat.o linux-fork.o linux-record.o record.o
 
 # The dynamically loaded libthread_db needs access to symbols in the
 # gdb executable.

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

[Pedro Alves]

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.

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

-- 
Pedro Alves

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

[Michael Snyder]

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.

OK, withdrawn.


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

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

[Hui Zhu]

Sorry.  I cannot agree with this patch.  It make record to be the
linux-special code.

Thanks,
Hui

On Fri, Oct 23, 2009 at 23:44, Michael Snyder <msnyder@vmware.com> 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.
>
> 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.
>
> Michael
>
>
> 2009-10-23  Michael Snyder  <msnyder@vmware.com>
>
>        * Makefile.in (COMMON_OBS): Remove record.o.
>        (ALL_TARGET_OBS): Remove linux-record.o.
>        config/i386/linux.h (NATDEPFILES): Add record.o, linux-record.o.
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/Makefile.in,v
> retrieving revision 1.1103
> diff -u -p -w -b -r1.1103 Makefile.in
> --- Makefile.in 21 Oct 2009 14:14:56 -0000      1.1103
> +++ Makefile.in 23 Oct 2009 15:45:31 -0000
> @@ -531,8 +531,7 @@ ALL_TARGET_OBS = \
>        xcoffread.o \
>        symfile-mem.o \
>        corelow.o \
> -       windows-tdep.o \
> -       linux-record.o
> +       windows-tdep.o
>
>  # Host-dependent makefile fragment comes in here.
>  @host_makefile_frag@
> @@ -834,7 +833,7 @@ COMMON_OBS = $(DEPFILES) $(CONFIG_OBS) $
>        solib.o solib-null.o \
>        prologue-value.o memory-map.o xml-support.o xml-syscall.o \
>        target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o \
> -       inferior.o osdata.o gdb_usleep.o record.o \
> +       inferior.o osdata.o gdb_usleep.o \
>        jit.o progspace.o
>
>  # Definitions for the syscall's XML files and dir
> Index: config/i386/linux.mh
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/i386/linux.mh,v
> retrieving revision 1.21
> diff -u -p -w -b -r1.21 linux.mh
> --- config/i386/linux.mh        14 Aug 2007 12:51:59 -0000      1.21
> +++ config/i386/linux.mh        23 Oct 2009 15:45:31 -0000
> @@ -4,7 +4,7 @@ NAT_FILE= nm-linux.h
>  NATDEPFILES= inf-ptrace.o fork-child.o \
>        i386-nat.o i386-linux-nat.o \
>        proc-service.o linux-thread-db.o gcore.o \
> -       linux-nat.o linux-fork.o
> +       linux-nat.o linux-fork.o linux-record.o record.o
>
>  # The dynamically loaded libthread_db needs access to symbols in the
>  # gdb executable.
>
>

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

[Michael Snyder]

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.

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.

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?

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

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

[Pedro Alves]

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

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

[Michael Snyder]

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.