This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp
- From: Christophe LYON <christophe dot lyon at st dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 30 Mar 2009 10:34:03 +0200
- Subject: Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp
- References: <49CCDB3D.5010302@st.com> <20090327184726.GW9472@adacore.com>
Hello Joel,
On 27.03.2009 19:47, Joel Brobecker wrote:
Hello Christophe,
2009-03-27 Christophe Lyon <christophe.lyon@st.com>
testsuite/
* gdb.base/step-line.exp: Fix pattern to allow full path before
"step-line.c".
I'd love to have some feedback from the other maintainers on this one.
My first observation is that it doesn't fail for me when testing
out-of-tree, using either DWARF or stabs. So I'm wondering why
this is failure in Chistophe's case. Perhaps a dump of your debugging
information (filename/dirname info for step-line.c and the line table
as well) would allows to understand the difference.
That being said, I don't see that we make a guaranty at the user-level
that the name of the file will be printed using either its full path or
just the basename, or anthing in the middle. So we could argue that
the output with the full path is equally valid and that the expected
output should therefore be enhanced to accept both.
WDYT?
I forgot to mention that before submitting the patch, I grepped in
gdb.base and gdb.cp to see how other tests expect the filename to be
printed. Maybe I missed some of them, but I noticed that step-line.c was
the only one not using .*$srcfile.
So I thought it had been forgotten.
Yet, this is not an explanation of why it fails :-)
I am not using GCC, but a retargetting of Open64 for one of our internal
targets. Maybe people from Tensilica or PathScale have already noticed
the same issue.
If I dump the Dwarf info (using dwarfdump and readelf), I can see the
full path name in DW_AT_name for the compile_unit (I tried to call
runtest with absolute and relative --srcdir, and in both cases the test
fails).
For DW_AT_comp_dir, I have the expected hostname:absolute_path string.
Comparing with GCC, there is a difference in the DW_AT_comp_dir, where
GCC does not print the hostname prefix. But my understanding of the
Dwarf spec is that hostname:path should be used, isn't it? Anyway GDB
seems to be able to cope with this (see read_file_scope in
dwarf2read.c). Still with GCC, I notice that if I use an absolute source
file name, there is no DW_AT_comp_dir.
To summarize, when using an absolute src file name:
* GCC:
DT_AT_name=absolute src file name
DW_AT_comp_dir: not present
Directory table in debug_line: absolute path to `dirname $srcfile`
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 step-line.c
2 0 0 0 step-line.c
3 0 0 0 step-line.inp
* Open64:
DT_AT_name=absolute src file name
DW_AT_comp_dir=hostname:absolute `pwd`
Directory table in debug_line:
- absolute path to `dirname $srcfile`
- absolute `pwd`
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 step-line.c
2 2 0 0 step-line.inp
So... it may be an issue with my compiler handling of #line?
Thanks,
Christophe.