This is the mail archive of the
mailing list for the GDB project.
Re: PATCH: gdb/corefile.c (0401 snap on HP-UX).
- To: RDBrown at mira dot net, RodneyBrown at mynd dot com, gdb-patches at sources dot redhat dot com
- Subject: Re: PATCH: gdb/corefile.c (0401 snap on HP-UX).
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 9 Apr 2001 10:17:14 -0700
- References: <E14mbKs-000059-00@urtur>
On Apr 9, 11:04pm, RDBrown@mira.net wrote:
> gdb/corefile.c was failing to compile with a missing declaration for
> `symfile_objfile'. This allows gdb to build, but still hangs when
> starting the child process.
> 2001-04-09 Rodney Brown <RBrown64@csc.com.au>
> * corefile.c: Include symfile.h and objfiles.h to declare
> symfile_objfile when HPUXHPPA.
> --- gdb/corefile.c.orig Mon Apr 9 18:45:13 2001
> +++ gdb/corefile.c Mon Apr 9 18:02:21 2001
> @@ -34,6 +34,10 @@
> #include "gdbcore.h"
> #include "dis-asm.h"
> #include "gdb_stat.h"
> +#ifdef HPUXHPPA
> +#include "symfile.h"
> +#include "objfiles.h"
> /* Local function declarations. */
I'd prefer to see a somewhat different solution.
The reason that symfile_objfile is undefined for HP is because of the
following code in core_file_command():
/* Yes, we were given the path of a core file. Do we already
have a symbol file? If not, can we determine it from the
core file? If we can, do so.
if (symfile_objfile == NULL)
symfile = t->to_core_file_to_sym_file (filename);
char *symfile_copy = xstrdup (symfile);
make_cleanup (xfree, symfile_copy);
symbol_file_add_main (symfile_copy, from_tty);
warning ("Unknown symbols for '%s'; use the 'symbol-file' command.", filename);
The code controlled by the above ifdef looks pretty generic and it seems
to me that it could be useful on targets other than HP. I suggest that
we do one of two things:
1) Enable it for all targets and add Rodney's #include statments
2) Remove it entirely.
I'm not familiar enough with the code in question to know what the best
course of action is.