This is the mail archive of the gdb-patches@sources.redhat.com 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: [patch/rfc] Build inf-ptrace.o when ptrace available


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


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
esac

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.

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


Andrew



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