This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Make sym_read routines handle separate debug files
- From: Tom Tromey <tromey at redhat dot com>
- To: Tristan Gingold <gingold at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 04 Dec 2009 11:01:54 -0700
- Subject: Re: [RFA] Make sym_read routines handle separate debug files
- References: <20091204124838.GA5764@ulanbator.act-europe.fr>
- Reply-to: tromey at redhat dot com
>>>>> "Tristan" == Tristan Gingold <email@example.com> writes:
Tristan> Each object file reader is now responsible to read separate
Tristan> debug files as they are object file dependant. Of course, in
Tristan> the case of gnu .debuglink a common subprogram is used.
You updated coffread and elfread, but the existing code in gdb does not
depend on the format. So it seems to me that any other code defining
sym_fns will regress. That is, dbxread, mipsread, somread, and
xcoffread (I omitted machoread since I presume your later patch fixes
Could we not just keep the existing logic as a format-independent
Or am I mistaken about something? Maybe it is impossible for those
formats to have separate debug files? I know nothing of the details,
Tristan> + debugfile = find_separate_debug_file_by_buildid (objfile);
If this is only meaningful for ELF, as it seems to be, then it seems we
might as well put it in elfread.c.
Tristan> +/* Add BFD as a separate debug file for OBJFILE. */
Tristan> +symbol_file_add_separate (bfd *bfd, int symfile_flags, struct objfile *objfile)
Tristan> + objfile->separate_debug_objfile =
I'm wondering if this should have a sanity check and call internal_error
if the separate debug objfile is already set.
Tristan> @@ -2320,204 +2314,217 @@ reread_symbols (void)
Tristan> + /* The "mainline" parameter is a hideous hack; I think leaving it
Tristan> + zero is OK since dbxread.c also does what it needs to do if
Tristan> + objfile->global_psymbols.size is 0. */
Normally I wouldn't ask for changes in a simple reindentation (and there
are other stale comments here that I didn't single out), but this
particular comment seems relevant to the overall change. I suggest just
removing it, but rewording would be ok too.