inconsistency in gdb/mi -file-list-exec-source-files

inconsistency in gdb/mi -file-list-exec-source-files

[Xavier de Gaye]

The output of '-file-list-exec-source-files' differs between gdb 7.2 and
gdb previous releases: with gdb 7.2 the 'fullname' attribute becomes the
file basename and the 'file' attribute becomes the full pathname. It was
the reverse previously.

Xavier

===   GDB 7.2   ======================================

gdb/gdb-git/gdb/build/gdb/gdb --interpreter=mi
=thread-group-added,id="i1"
~"GNU gdb (GDB) 7.2.50.20100724-cvs\n"
~"Copyright (C) 2010 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>\nThis is free software: you are free
to change and redistribute it.\nThere is NO WARRANTY, to the extent
permitted by law.  Type \"show copying\"\nand \"show warranty\" for
details.\n"
~"This GDB was configured as \"x86_64-unknown-linux-gnu\".\nFor bug
reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
(gdb)
-file-exec-and-symbols testsuite/foobar
^done
(gdb)
-file-list-exec-source-files
^done,files=[{file="",fullname="/home/aurel32/debian/co-packages/glibc/
glibc-2.7/build-tree/amd64-libc/csu/crtn.S"},{file="",fullname="bar.c"},
{file="/home/xavier/src/pyclewn-hg-working/testsuite/bar.c",fullname="bar.c"},
{file="",fullname="foo.c"},
{file="/home/xavier/src/pyclewn-hg-working/testsuite/foo.c",fullname="foo.c"},
{file="",fullname="foobar.c"},
{file="/home/xavier/src/pyclewn-hg-working/testsuite/foobar.c",fullname="foobar.c"},
{file="",fullname="/home/aurel32/debian/co-packages/glibc/glibc-2.7/build-tree/amd64-libc/csu/crti.S"},
{file="",fullname="init.c"}]
(gdb)

===   GDB 6.8   ======================================

/usr/bin/gdb  --interpreter=mi
~"GNU gdb 6.8-debian\n"
~"Copyright (C) 2008 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>\n"
~"This is free software: you are free to change and redistribute it.\n"
~"There is NO WARRANTY, to the extent permitted by law.  Type \"show
copying\"\n"
~"and \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\n"
(gdb)
-file-exec-and-symbols testsuite/foobar
^done
(gdb)
-file-list-exec-source-files
^done,files=[{file="/home/aurel32/debian/co-packages/glibc/glibc-2.7/build-tree/amd64-libc/csu/crtn.S"},
{file="bar.c"},
{file="bar.c",fullname="/home/xavier/src/pyclewn-hg-working/testsuite/bar.c"},
{file="foo.c"},
{file="foo.c",fullname="/home/xavier/src/pyclewn-hg-working/testsuite/foo.c"},
{file="foobar.c"},
{file="foobar.c",fullname="/home/xavier/src/pyclewn-hg-working/testsuite/foobar.c"},
{file="/home/aurel32/debian/co-packages/glibc/glibc-2.7/build-tree/amd64-libc/csu/crti.S"},{file="init.c"}]
(gdb)

Re: inconsistency in gdb/mi -file-list-exec-source-files

[Daniel Jacobowitz]

On Thu, Jul 29, 2010 at 04:41:49PM +0200, Xavier de Gaye wrote:
> The output of '-file-list-exec-source-files' differs between gdb 7.2 and
> gdb previous releases: with gdb 7.2 the 'fullname' attribute becomes the
> file basename and the 'file' attribute becomes the full pathname. It was
> the reverse previously.

The MI code has not changed so this must be an issue in symtabs,
probably in dwarf2read.  IMO, this is pretty serious for the release.

-- 
Daniel Jacobowitz
CodeSourcery

Re: inconsistency in gdb/mi -file-list-exec-source-files

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <dan@codesourcery.com> writes:

Daniel> On Thu, Jul 29, 2010 at 04:41:49PM +0200, Xavier de Gaye wrote:
>> The output of '-file-list-exec-source-files' differs between gdb 7.2 and
>> gdb previous releases: with gdb 7.2 the 'fullname' attribute becomes the
>> file basename and the 'file' attribute becomes the full pathname. It was
>> the reverse previously.

Daniel> The MI code has not changed so this must be an issue in symtabs,
Daniel> probably in dwarf2read.  IMO, this is pretty serious for the release.

I made a note on the 7.2 page on the wiki.
I would be happy to look into this (I assume it is my fault :-).
I'll be away next week, though, so I can't start until Aug 9.

Tom