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.

0 files changed, 0 insertions, 0 deletions