[patch/rfc] Build inf-ptrace.o when ptrace available
Wed Oct 13 13:54:00 GMT 2004
On Mon, Oct 11, 2004 at 01:23:56PM -0400, Andrew Cagney wrote:
> >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.
> So you're not objecting to changes making configure (actually
> configure.host and configure.tgt) directly handle what was previously in
> the .mh file ...
I thought I was being quite clear. You've presented two suggestions:
- use autoconf to build inf-ptrace
- goal: move natfiles into lists in the configure scripts
I've said that I object to them both. I object strongly to the first,
and stylisticly to the second.
> >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.
> .. but rather just objecting to having inf-ptrace selected dependant on
> autoconf magic? I could equally hardwire it vis:
> case $host in
> *-linux* | *-bsd* ) objs += inf-ptrace
> Can you show us the money here - on what systems did you encounter
> problems and what problems were they?
> The most recent problem I can think of was with the TUI, and that was a
> straight configure.in bug.
I wrote that my experience with automated builds suggested that a
problem _would_ occur. I don't have an example of this problem
occuring, but I don't think we need one to understand why it is an
unsound design principle. The change would cause inf-ptrace to be
built on more systems/configurations (where GDB wouldn't know how to
use it), and could potentially cause it to be built on fewer systems
(where GDB wouldn't work without it). No win.
> >>>>>>>>>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.
> So initially we can migrate things to configure.host, and then, if
> things prove to unwieldly, look at refactoring it. But not before.
So move everything out of makefile fragments before considering
refactoring the makefile fragments? That doesn't make any sense.
I will continue to object when you present this as a change with valid
technical/maintenance advantages. If other maintainers agree that it
has better style, I won't object to making the change, I've already
said that. But I don't want to make a gratuituous change in style for
bogus technical reasons. Something which can obviously be done in the
current system is not a valid technical reason to discard the current
More information about the Gdb-patches