RFA: libunwind basic support
Fri Nov 14 00:06:00 GMT 2003
> It is possible for the user to enable libunwind but the header files are not there. I am guessing you would prefer compilation to fail in this case so I have removed the check.
Yes. If the user forces the use of libunwind, but it isn't there, the
user should loose.
> I have added comments for the search unwind table call.
> Index: configure.in
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.132
> diff -u -r1.132 configure.in
> --- configure.in 3 Sep 2003 15:02:48 -0000 1.132
> +++ configure.in 22 Oct 2003 23:36:21 -0000
> @@ -192,6 +192,33 @@
> enable_gdbtk=no ;;
> Based on 12.1 Working With External Software
> I suspect that this should be --with (external libunwind software), and not --enable (gdb feature), although, to be honest, its hard to tell which it should be.
> From discussions with Jeff Law when I was doing configuration for newlib, he told me that --enable should be used for on/off decisions in preference to --with. I don't personally care so I have switched to --with.
You're right that the lines are blured. enable/disable is for
controlling the presence of an internal feature while with/without is
for controlling a dependency/use of an external program, or library.
Unfortunatly, here the decision to build GDB with/without the external
libunwind library has the consequence of determining if GDB should
enable/disable the internal (but not user visible) libunwind unwinder.
I think, based on the presence of X as an example in the manual, the
with/without takes precidence.
So, yes all ok.
> Index: libunwind-frame.c
More information about the Gdb-patches