bug in gdb.mi/mi-file.exp (or maybe in GDB)

bug in gdb.mi/mi-file.exp (or maybe in GDB)

[David Carlton]

When I run gdb.mi/mi-file.exp, I get this failure:

FAIL: gdb.mi/mi-file.exp: request path info of current source file (basics.c)

Presumably nobody else is seeing this because I'm the only weirdo who
builds in source.  I think it's probably a testsuite bug instead of a
GDB bug, but I don't know exactly what the relevant MI command is
supposed to do, so I'll just show you what I'm seeing: gdb.log says:

  111^done,line="23",file="gdb.mi/basics.c",fullname="/extra/gdb/mirror/src/gdb/testsuite/gdb.mi/basics.c"

whereas mi-file.exp is looking for:

  "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\""

where ${srcfilepath} is defined by:

  set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]

So the test seems to expect 'file' to be the fully qualified path and
for 'fullname' to be anything random that starts with a slash and ends
right.  Whereas I'm not getting a fully qualified path for 'file'.

So: is 'file' really supposed to be a fully qualified path?  If so,
what's the difference between 'file' and 'fullname'?  (Judging from
the manual, I don't see why 'file' should be an absolute path, but
maybe I'm missing something.)  Should 'file' match .*${srcfile}
(without any slashes) and 'fullname' match ${srcfilepath}?

Also, should gdb.mi have its own ChangeLog?  It's being used
inconsistently, since most of the recent entries got put in
testsuite/ChangeLog.

David Carlton
carlton@math.stanford.edu

Re: bug in gdb.mi/mi-file.exp (or maybe in GDB)

[Bob Rossi]

On Wed, Apr 09, 2003 at 01:01:41PM -0700, David Carlton wrote:
> When I run gdb.mi/mi-file.exp, I get this failure:
> 
> FAIL: gdb.mi/mi-file.exp: request path info of current source file (basics.c)
> 
> Presumably nobody else is seeing this because I'm the only weirdo who
> builds in source.  I think it's probably a testsuite bug instead of a
> GDB bug, but I don't know exactly what the relevant MI command is
> supposed to do, so I'll just show you what I'm seeing: gdb.log says:
> 
>   111^done,line="23",file="gdb.mi/basics.c",fullname="/extra/gdb/mirror/src/gdb/testsuite/gdb.mi/basics.c"
> 
> whereas mi-file.exp is looking for:
> 
>   "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\""

This is what I get, which passes
111^done,line="23",file="./gdb.mi/basics.c",fullname="/home/bob/cvs/src/gdb/testsuite/gdb.mi/basics.c"^

> 
> where ${srcfilepath} is defined by:
> 
>   set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
> 
> So the test seems to expect 'file' to be the fully qualified path and
> for 'fullname' to be anything random that starts with a slash and ends
> right.  Whereas I'm not getting a fully qualified path for 'file'.
> So: is 'file' really supposed to be a fully qualified path?  If so,
> what's the difference between 'file' and 'fullname'? 

file should be the path that gdb has always produced. The relative path
to the source file given from where it was compiled. Its basically what
you should get when you do 'info sources'.

fullname should be the absolute path to the source file.
I only tested it for starting with a / and ending with basics.c because
that seemed to be a good and easy way to ensure the file was absolute.

> Should 'file' match .*${srcfile}
> (without any slashes) and 'fullname' match ${srcfilepath}?

I think your suggestion of what file should match is a good one.
The fullname match should probably not change. Since ${srcfilepath} is not
guaranteed to be the absolute path to the source file.

> Also, should gdb.mi have its own ChangeLog?  It's being used
> inconsistently, since most of the recent entries got put in
> testsuite/ChangeLog.
> 
> David Carlton
> carlton@math.stanford.edu

Re: bug in gdb.mi/mi-file.exp (or maybe in GDB)

[David Carlton]

On Wed, 9 Apr 2003 16:30:24 -0400, Bob Rossi <bob_rossi@cox.net> said:
> On Wed, Apr 09, 2003 at 01:01:41PM -0700, David Carlton wrote:

>> gdb.log says:
>> 
>> 111^done,line="23",file="gdb.mi/basics.c",fullname="/extra/gdb/mirror/src/gdb/testsuite/gdb.mi/basics.c"

> This is what I get, which passes
> 111^done,line="23",file="./gdb.mi/basics.c",fullname="/home/bob/cvs/src/gdb/testsuite/gdb.mi/basics.c"^

Ah. I guess maybe different versions of GCC differ as to whether or
not they include the './' in the filename in the debug info, or
something.

>> Should 'file' match .*${srcfile}
>> (without any slashes) and 'fullname' match ${srcfilepath}?

> I think your suggestion of what file should match is a good one.

Elena just raised a similar issue in annota1.exp.  So maybe we should
wait for the resolution there and then adopt the same solution for
'file' here.  (Though the format of 'file' is less crucial here, since
that's what 'fullname' is for.)

> The fullname match should probably not change. Since ${srcfilepath}
> is not guaranteed to be the absolute path to the source file.

Oh, right, duh.  I should have tested that before suggesting it!

David Carlton
carlton@math.stanford.edu

Re: bug in gdb.mi/mi-file.exp (or maybe in GDB)

[Elena Zannoni]

David Carlton writes:
 > When I run gdb.mi/mi-file.exp, I get this failure:
 > 
 > FAIL: gdb.mi/mi-file.exp: request path info of current source file (basics.c)
 > 
 > Presumably nobody else is seeing this because I'm the only weirdo who
 > builds in source.  I think it's probably a testsuite bug instead of a
 > GDB bug, but I don't know exactly what the relevant MI command is
 > supposed to do, so I'll just show you what I'm seeing: gdb.log says:
 > 
 >   111^done,line="23",file="gdb.mi/basics.c",fullname="/extra/gdb/mirror/src/gdb/testsuite/gdb.mi/basics.c"
 > 
 > whereas mi-file.exp is looking for:
 > 
 >   "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\""
 > 
 > where ${srcfilepath} is defined by:
 > 
 >   set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
 > 
 > So the test seems to expect 'file' to be the fully qualified path and
 > for 'fullname' to be anything random that starts with a slash and ends
 > right.  Whereas I'm not getting a fully qualified path for 'file'.
 > 
 > So: is 'file' really supposed to be a fully qualified path?  If so,
 > what's the difference between 'file' and 'fullname'?  (Judging from
 > the manual, I don't see why 'file' should be an absolute path, but
 > maybe I'm missing something.)  Should 'file' match .*${srcfile}
 > (without any slashes) and 'fullname' match ${srcfilepath}?
 > 

Hmm, I suspect you are right. They should be swapped. Fullname should be
the complete path. 

 > Also, should gdb.mi have its own ChangeLog?  It's being used
 > inconsistently, since most of the recent entries got put in
 > testsuite/ChangeLog.
 > 

This is just a historical accident. The MI was contributed by
Cygnus after it already had its own Changelogs, and a .texi file.


elena


 > David Carlton
 > carlton@math.stanford.edu

Re: bug in gdb.mi/mi-file.exp (or maybe in GDB)

[Elena Zannoni]

David Carlton writes:
 > On Wed, 9 Apr 2003 16:30:24 -0400, Bob Rossi <bob_rossi@cox.net> said:
 > > On Wed, Apr 09, 2003 at 01:01:41PM -0700, David Carlton wrote:
 > 
 > >> gdb.log says:
 > >> 
 > >> 111^done,line="23",file="gdb.mi/basics.c",fullname="/extra/gdb/mirror/src/gdb/testsuite/gdb.mi/basics.c"
 > 
 > > This is what I get, which passes
 > > 111^done,line="23",file="./gdb.mi/basics.c",fullname="/home/bob/cvs/src/gdb/testsuite/gdb.mi/basics.c"^
 > 
 > Ah. I guess maybe different versions of GCC differ as to whether or
 > not they include the './' in the filename in the debug info, or
 > something.
 > 

Compiling and building everything with absolute paths in build!=src, I
get absolute paths in both.

111^done,line="23",file="/home/ezannoni/sources/src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/ezannoni/sources/src/gdb/testsuite/gdb.mi/basics.c"

 > >> Should 'file' match .*${srcfile}
 > >> (without any slashes) and 'fullname' match ${srcfilepath}?
 > 
 > > I think your suggestion of what file should match is a good one.
 > 
 > Elena just raised a similar issue in annota1.exp.  So maybe we should
 > wait for the resolution there and then adopt the same solution for
 > 'file' here.  (Though the format of 'file' is less crucial here, since
 > that's what 'fullname' is for.)
 >  

All I care about it to match correctly with '+' in the directory
names. So maybe all I need is to use string_to_regexp and leave the
full path in there.

 > > The fullname match should probably not change. Since ${srcfilepath}
 > > is not guaranteed to be the absolute path to the source file.
 > 
 > Oh, right, duh.  I should have tested that before suggesting it!
 > 

Ah right, ${srcfilepath} is set up by the testsuite machinery, not
gdb, so it is not guaranteed to match fullname.  I thought you meant
that fullname could not be absolute, and that got me puzzled.  Bottom
line, the testsuite doesn't know what the absolute path is.  We could
pull the dirty trick of asking gdb for it, with an 'info source' and
use that output to match.


elena


 > David Carlton
 > carlton@math.stanford.edu

Re: bug in gdb.mi/mi-file.exp (or maybe in GDB)

[Bob Rossi]

On Wed, Apr 09, 2003 at 05:25:52PM -0400, Elena Zannoni wrote:
> David Carlton writes:
>  > On Wed, 9 Apr 2003 16:30:24 -0400, Bob Rossi <bob_rossi@cox.net> said:
>  > > On Wed, Apr 09, 2003 at 01:01:41PM -0700, David Carlton wrote:
>  > 
>  > >> gdb.log says:
>  > >> 
>  > >> 111^done,line="23",file="gdb.mi/basics.c",fullname="/extra/gdb/mirror/src/gdb/testsuite/gdb.mi/basics.c"
>  > 
>  > > This is what I get, which passes
>  > > 111^done,line="23",file="./gdb.mi/basics.c",fullname="/home/bob/cvs/src/gdb/testsuite/gdb.mi/basics.c"^
>  > 
>  > Ah. I guess maybe different versions of GCC differ as to whether or
>  > not they include the './' in the filename in the debug info, or
>  > something.
>  > 
> 
> Compiling and building everything with absolute paths in build!=src, I
> get absolute paths in both.
> 
> 111^done,line="23",file="/home/ezannoni/sources/src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/ezannoni/sources/src/gdb/testsuite/gdb.mi/basics.c"
> 
>  > >> Should 'file' match .*${srcfile}
>  > >> (without any slashes) and 'fullname' match ${srcfilepath}?
>  > 
>  > > I think your suggestion of what file should match is a good one.
>  > 
>  > Elena just raised a similar issue in annota1.exp.  So maybe we should
>  > wait for the resolution there and then adopt the same solution for
>  > 'file' here.  (Though the format of 'file' is less crucial here, since
>  > that's what 'fullname' is for.)
>  >  
> 
> All I care about it to match correctly with '+' in the directory
> names. So maybe all I need is to use string_to_regexp and leave the
> full path in there.
> 
>  > > The fullname match should probably not change. Since ${srcfilepath}
>  > > is not guaranteed to be the absolute path to the source file.
>  > 
>  > Oh, right, duh.  I should have tested that before suggesting it!
>  > 
> 
> Ah right, ${srcfilepath} is set up by the testsuite machinery, not
> gdb, so it is not guaranteed to match fullname.  I thought you meant
> that fullname could not be absolute, and that got me puzzled.  Bottom
> line, the testsuite doesn't know what the absolute path is.  We could
> pull the dirty trick of asking gdb for it, with an 'info source' and
> use that output to match.

I think if we did that, they might break consistently, and the test case
could still pass. It seems like maybe we should allow the file to match
the same thing we allow fullname to match. "/.*$(srcfile}" Since it is legal.

Bob Rossi

> 
> 
> elena
> 
> 
>  > David Carlton
>  > carlton@math.stanford.edu

Re: bug in gdb.mi/mi-file.exp (or maybe in GDB)

[Elena Zannoni]

Bob Rossi writes:
 
 > > Ah right, ${srcfilepath} is set up by the testsuite machinery, not
 > > gdb, so it is not guaranteed to match fullname.  I thought you meant
 > > that fullname could not be absolute, and that got me puzzled.  Bottom
 > > line, the testsuite doesn't know what the absolute path is.  We could
 > > pull the dirty trick of asking gdb for it, with an 'info source' and
 > > use that output to match.
 > 
 > I think if we did that, they might break consistently, and the test case
 > could still pass. It seems like maybe we should allow the file to match
 > the same thing we allow fullname to match. "/.*$(srcfile}" Since it is legal.

Yes, but the purpose of the mi testsuite is to check consistency
between what the cli produces and what the mi produces. It is not the
case that we want to verify that 'info source' works. For that there
should be a test in gdb.base (BTW, is there one?)
But anyway, I don't feel strongly ether way. 

elena