Fix regression in -file-list-exec-source-files command.
See http://sourceware.org/ml/gdb/2010-07/msg00118.html for
a description of the problem. Namely, the file and fullname
fields are inverted in the output of the -file-list-exec-source-files
GDB/MI command:
(gdb) interpreter-exec mi -file-list-exec-source-files
^done,files=[{file="/takamaka.a/brobecke/ex/list-exec-source-files/foo.c",fullname="foo.c"},{file="/takamaka.a/brobecke/ex/list-exec-source-files/foo.c",fullname="foo.c"},{file="",fullname="init.c"},{file="",fullname="../sysdeps/x86_64/elf/start.S"},{file="",fullname="../sysdeps/x86_64/elf/start.S"}]
It turns out to be a silly thinko: The map_symbol_filenames function
calls the psymtab version of map_symbol_filenames routine, and this
version called the callback function with filename and fullname
in the wrong order (fullname/filename instead of filename/fullname).
The routine description in symfile.h confirst that expected order for
the FUN callback parameters:
/* Call a callback for every file defined in OBJFILE. FUN is the
callback. It is passed the file's name, the file's full name,
and the DATA passed to this function. */
void (*map_symbol_filenames) (struct objfile *objfile,
void (*fun) (const char *, const char *,
void *),
void *data);
Fixing this error uncovered another location where the arguments
were reversed: maybe_add_partial_symtab_filename. Once the first
error was fixed, the debugger would crash while attempting to do
completion, because it was given a NULL fullname instead of the
non-NULL filename.
gdb/ChangeLog:
* psymtab.c (map_symbol_filenames_psymtab): Call FUN with
the arguments in the correct order.
* symtab.c (maybe_add_partial_symtab_filename): Declare
the arguments in the correct order.