[PATCH] obvious pattern fix in gdb.base/step-line.exp

[PATCH] obvious pattern fix in gdb.base/step-line.exp

[Christophe LYON]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

Hello,

I propose the attached small patch to allow printing the full path 
before 'step-line.c'.

Christophe.

[-- Attachment #2: gdb.step-line.changelog --]
[-- Type: text/plain, Size: 148 bytes --]

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".

[-- Attachment #3: gdb.step-line.patch --]
[-- Type: text/plain, Size: 546 bytes --]

Index: gdb/testsuite/gdb.base/step-line.exp
===================================================================
--- gdb/testsuite/gdb.base/step-line.exp	(revision 308)
+++ gdb/testsuite/gdb.base/step-line.exp	(working copy)
@@ -46,7 +46,7 @@ if ![runto_main] then {
    return 0
 }
 
-gdb_test "break f1" ".*Breakpoint 2 at .* file step-line.c.*" "break f1"
+gdb_test "break f1" ".*Breakpoint 2 at .* file .*$srcfile.*" "break f1"
 gdb_test "continue" \
          "Continuing.*Breakpoint 2, f1 \\(i=4\\).*dummy \\(1, i\\);" \
 	 "continue to f1"

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Joel Brobecker]

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?

> Index: gdb/testsuite/gdb.base/step-line.exp
> ===================================================================
> --- gdb/testsuite/gdb.base/step-line.exp	(revision 308)
> +++ gdb/testsuite/gdb.base/step-line.exp	(working copy)
> @@ -46,7 +46,7 @@ if ![runto_main] then {
>     return 0
>  }
>  
> -gdb_test "break f1" ".*Breakpoint 2 at .* file step-line.c.*" "break f1"
> +gdb_test "break f1" ".*Breakpoint 2 at .* file .*$srcfile.*" "break f1"
>  gdb_test "continue" \
>           "Continuing.*Breakpoint 2, f1 \\(i=4\\).*dummy \\(1, i\\);" \
>  	 "continue to f1"

-- 
Joel

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Christophe LYON]

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.

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Joel Brobecker]

> So... it may be an issue with my compiler handling of #line?

Not quite sure from the dump what exactly causes the change of behavior,
I would need to look at the code more precisely, and I'm a little rush
right now.

But since I believe that printing the full name is perfectly valid (in
fact, I later verified that this is what happens with Ada files as well,
even though the debug info looks similar to what we get with step-line.c),
it's fine to commit your patch.

-- 
Joel

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Christophe LYON]

On 30.03.2009 19:02, Joel Brobecker wrote:
>> So... it may be an issue with my compiler handling of #line?
> 
> Not quite sure from the dump what exactly causes the change of behavior,
> I would need to look at the code more precisely, and I'm a little rush
> right now.
> 
> But since I believe that printing the full name is perfectly valid (in
> fact, I later verified that this is what happens with Ada files as well,
> even though the debug info looks similar to what we get with step-line.c),
> it's fine to commit your patch.
> 
Hi Joel,

I have investigated a bit more... and I think I found a bug in our compiler.

But I am not 100% sure how to interpret the ANSI C spec regarding the 
#line directive: when the name of the source file has no path (as in 
step-line.c, where #line xx "step-line.c" is used), which path should be 
considered?

Indeed, as mentioned before, my compiler generates the following file table:
   Entry Dir     Time    Size    Name
   1     1       0       0       step-line.c
   2     2       0       0       step-line.inp

while GCC generates:
   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
(and uses the 2nd entry for the #line directives).

I changed my compiler to behave as GCC, and I got the same behavior 
under GDB.

So... is this a bug in the test, in my compiler? If in my compiler, then 
I am not sure it's a good idea to apply my fix to the testsuite :-)

Thanks,

Christophe.

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Joel Brobecker]

> But I am not 100% sure how to interpret the ANSI C spec regarding the  
> #line directive: when the name of the source file has no path (as in  
> step-line.c, where #line xx "step-line.c" is used), which path should be  
> considered?

Not sure either. Perhaps it's just unspecified?

> So... is this a bug in the test, in my compiler? If in my compiler,
> then  I am not sure it's a good idea to apply my fix to the testsuite
> :-)

I'm OK with leaving the testcase untouched if we don't need to.
However, I think it's worth mentioning again what happens in
the Ada case:

    % gnatmake -g `pwd`/foo
    gcc -c -I/home/brobecke/toto/ -g -I- /home/brobecke/toto/foo.adb
    gnatbind -x foo.ali
    gnatlink foo.ali -g

Then inserting a breakpoint on procedure Foo:

    (gdb) b foo
    Breakpoint 1 at 0x401f0c: file /home/brobecke/toto/foo.adb, line 4.

In my opinion, the current behavior in that case is fine too.

-- 
Joel

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Christophe LYON]

On 01.04.2009 20:32, Joel Brobecker wrote:
>> But I am not 100% sure how to interpret the ANSI C spec regarding the  
>> #line directive: when the name of the source file has no path (as in  
>> step-line.c, where #line xx "step-line.c" is used), which path should be  
>> considered?
> 
> Not sure either. Perhaps it's just unspecified?
> 
I would say so, too.


> I'm OK with leaving the testcase untouched if we don't need to.
OK. So I won't commit my patch, and fix the compiler instead.

Thanks
Christophe.

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Christophe LYON]

> 
>> I'm OK with leaving the testcase untouched if we don't need to.
> OK. So I won't commit my patch, and fix the compiler instead.
> 

I have been trying to fix the compiler so that it behaves like GCC 
(using 2 separate filenames for the actual source file and for the one 
provided with #line), but I get regressions later in step-line.exp.

After dumping the debug_line info (with readelf and/or dwarfdump), I 
mostly noticed that the file number has changed according to the 
compiler fix.

However, from GDB, using "maintenance print symbols", I noticed that 
quite a few lines have become "0" instead of meaningful values. In turn, 
I thinks this makes skip_prologue do something wrong.

What I dont' understand currently is where those "0" line entries come 
from? Is there any verbose flag or maintenance command I could use to 
understand how the Dwarf debug_line info is parsed?

Thanks,

Christophe.

Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp

[Daniel Jacobowitz]

On Fri, Apr 17, 2009 at 07:06:09PM +0200, Christophe LYON wrote:
> However, from GDB, using "maintenance print symbols", I noticed that  
> quite a few lines have become "0" instead of meaningful values. In turn,  
> I thinks this makes skip_prologue do something wrong.
>
> What I dont' understand currently is where those "0" line entries come  
> from? Is there any verbose flag or maintenance command I could use to  
> understand how the Dwarf debug_line info is parsed?

Not really, but it's pretty straightforward to step through.

GDB uses line 0 internally to represent a lack of line number
information.  This is required because the line table uses
half-ranges; a line number and a start address.  We get a line
0 at file switch events or at DW_LNS_end_of_sequence.  There's
some hairy bits to make sure the 0 appears 'before' any other line
marker at the same address.

-- 
Daniel Jacobowitz
CodeSourcery