Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Oct 05, 2004 at 06:43:51PM -0400, Andrew Cagney wrote:
> >We can't "get GNU/Linux [...] using procfs".
> 
> Is there a technical problem blocking this?

The fact that the idea has been "under discussion but no one cares
enough to devote two months of programming to it" for at least three
years now?  The fact that there's no obvious user-visible improvement
associated with the huge amount of kernel-side work involved?  I think
those are technical problems.

This, however, is hugely off-topic for the original patch.

I still do not believe that configure testing should be used for this
purpose.  If we end up moving the knowledge of natfiles into configure,
then we can set inf-ptrace to be included for all native GNU/Linux
targets easily enough.  Or there are other ways to do it, as below. 

One of the reasons why I hold this position is that it lets us give a
more useful error message if someone's system is broken and can not
compile inf-ptrace.c for some reason that the configure script
detected.  They'll get either a link failure or a GDB which can't debug
anything, instead of an error related to the compile problem.  My
experience with automating distribution builds tells me that someone
will come up with a way to break their system in this fashion.

> >>>Why is it orthogonal?  If we assume that configure determines when /proc 
> >>>and ptrace() and provides both to the user it certainly isn't.  Idea's 
> >>>such as Mark's and mine would make it easier.
> >
> >
> >Why is it related?  How would this make it easier?  It's not hard to
> >add a new backend file to all the Linux targets; it's really not much
> >different in a lot of little files than in one big one.  I've done this
> >plenty of times.
> 
> If we used configure.tgt and:
> 	switch "$target"
> 	 *-*-linux* ) "objs=objs symfile-mem.c"
> 	esac
> then all GNU/Linux systems will always and consistently include 
> symtab-mem.c.  We don't, they don't ...

This is no harder than having a common linux.mh, as GCC has done for
years (gcc/config/t-linux).  It's not a technical differece between
configure-frobbing and makefile-fragmenting.

> We've already got configure.tgt checking OSABI and configure.host 
> checking FLOATFORMAT so there's plenty of prior art.  Further, 
> modifying/merging just that file is going to be a lot easier than 
> modifying/merging all the individual *.mh files.

I already said that I disagree with your "further".

-- 
Daniel Jacobowitz