Re: [RFA] new test for separate debug info

Michael Elizabeth Chastain
2004-01-13T05:19:15Z

Okay, I just ran it on spe191.testdrive.hp.com to see what happens.
What happens is:

(gdb) info source
Current source file is /house/chastain/gdb/s1/gdb/testsuite/gdb.base/sepdebug.c
Located in /house/chastain/gdb/s1/gdb/testsuite/gdb.base/sepdebug.c
Contains 150 lines.
Source language is c.
Compiled with unknown debugging format.
Does not include preprocessor macro info.
(gdb) UNSUPPORTED: gdb.base/sepdebug.exp: no separate debug info handling
testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/sepdebug.exp completed in 0 seconds

This is with HP Ansi C B.11.11.28707.GP.

I'm happy with this outcome, although I am not happy that "info source"
prints "compiled with unknown debugging format". I will investigate and
file a PR.

Also, the message does not happen because of "unknown debugging format".
It happens because I don't have gnu binutils in my $PATH, and the HP-UX
strip barfs on "--strip-debug".

I haven't set up a test bed for gcc + binutils on this platform yet,
just the native tools. I did try GNU strip from binutils 2.14 on
a hello-world program with "strip --strip-debug hello" and it didn't
complain.

By the way, HP Ansi C and HP C++ have an objdebug switch:

+objdebug This option when used with any of the -g options will
cause the debug information to be left in the object
files instead of being placed in the a.out. This will
bypass the pxdb step and the links will be faster.
Available only for wdb(1) or gdb(1). +noobjdebug is
the default at compile time. +noobjdebug can be used
at link time to continue to place the debug info into
the a.out, even if some objects were compiled with
+objdebug.
NOTE: Object files or archive libraries must not be
removed if this new method of debugging is used.

Michael C