Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Fernando Nasser]

From a discussion in gdb-patches

Michael Snyder wrote:
> 
> (...) we need some kind of test that applies
> the xfails for stabs and not for dwarf.
> 

There are so many instances where this would be useful that I would
like to suggest a "gdb_debug_format" procedure to be added to gdb.exp
that would determine that.

We could use a binutils utility on the test file (which we know) and
parse the output.  Does that seem reasonable?  Any other suggestions?

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Stan Shebs]

Fernando Nasser wrote:
> 
> >From a discussion in gdb-patches
> 
> Michael Snyder wrote:
> >
> > (...) we need some kind of test that applies
> > the xfails for stabs and not for dwarf.
> >
> 
> There are so many instances where this would be useful that I would
> like to suggest a "gdb_debug_format" procedure to be added to gdb.exp
> that would determine that.

Seems like a good idea to me too.

> We could use a binutils utility on the test file (which we know) and
> parse the output.  Does that seem reasonable?  Any other suggestions?

I can't think of a completely reliable test on binary files.  For
instance, in original a.out, stabs are plain symbols, not in a
distinctly-named section.  You also have the problem of an executable
maybe having libraries compiled with stabs, and main prog with dwarf,
and objdump can't distinguish.

On the other, grepping an assembly file produced via -S seems
reliable, since stabs always have at least one ".stabs" line,
and dwarf-2 will always have a .debug_info section mentioned, etc.
All of the compilers that GDB works with have a -S option.

Stan

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Fernando Nasser]

Hi Stan,

Thanks for your comments.

Stan Shebs wrote:
> 
> I can't think of a completely reliable test on binary files.  For
> instance, in original a.out, stabs are plain symbols, not in a
> distinctly-named section.  You also have the problem of an executable
> maybe having libraries compiled with stabs, and main prog with dwarf,
> and objdump can't distinguish.
> 

True.

I was thinking just in terms of the testsuite.  Most test programs are
a single file.  Could we test just the object file for that one?

Another idea: if we can't say t is stabs but we can say it is dwarf,
we could implement a gdb_is_dwarf instead.  Would that help?

Regards,
Fernando


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Elena Zannoni]

Fernando Nasser writes:
 > Hi Stan,
 > 
 > Thanks for your comments.
 > 
 > Stan Shebs wrote:
 > > 
 > > I can't think of a completely reliable test on binary files.  For
 > > instance, in original a.out, stabs are plain symbols, not in a
 > > distinctly-named section.  You also have the problem of an executable
 > > maybe having libraries compiled with stabs, and main prog with dwarf,
 > > and objdump can't distinguish.
 > > 
 > 
 > True.
 > 
 > I was thinking just in terms of the testsuite.  Most test programs are
 > a single file.  Could we test just the object file for that one?

I have seen cases in which we have both a .mdebug and a .stabs (or was
that dwarf2) sections (for the same program segment), and even gdb
itself gets confused as to which one is the reliable debug
info. Frankly I wouldn't be able to say exactly under which
circumstances you get this, but I have seen it.

I think this is basically what Stan is saying, the heuristic is
unreliable.

Elena


 > 
 > Another idea: if we can't say t is stabs but we can say it is dwarf,
 > we could implement a gdb_is_dwarf instead.  Would that help?
 > 
 > Regards,
 > Fernando
 > 
 > 
 > -- 
 > Fernando Nasser
 > Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
 > 2323 Yonge Street, Suite #300
 > Toronto, Ontario   M4P 2C9

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Fernando Nasser]

Elena Zannoni wrote:
> 
> Fernando Nasser writes:
>  > Hi Stan,
>  >
>  > Thanks for your comments.
>  >
>  > Stan Shebs wrote:
>  > >
>  > > I can't think of a completely reliable test on binary files.  For
>  > > instance, in original a.out, stabs are plain symbols, not in a
>  > > distinctly-named section.  You also have the problem of an executable
>  > > maybe having libraries compiled with stabs, and main prog with dwarf,
>  > > and objdump can't distinguish.
>  > >
>  >
>  > True.
>  >
>  > I was thinking just in terms of the testsuite.  Most test programs are
>  > a single file.  Could we test just the object file for that one?
> 
> I have seen cases in which we have both a .mdebug and a .stabs (or was
> that dwarf2) sections (for the same program segment), and even gdb
> itself gets confused as to which one is the reliable debug
> info. Frankly I wouldn't be able to say exactly under which
> circumstances you get this, but I have seen it.
> 
> I think this is basically what Stan is saying, the heuristic is
> unreliable.
> 

When you mean that gdb itself gets confused what is the end result of
that?
Does it pick one at the end (after a warning or something)?

Another question: does it happen even with the simple testsuite
programs?

If it is that unreliable, we could make sure the tests run with dwarf
only
when we are sure it is there and skip when we are not sure (if we can
determine that we are not sure from some gdb warning message).

P.S.: We can also be more aggressive and try and see where gdb gets
confused
and thinks it is dwarf (and so fail the tests).  We could dig for the
reason
that happens.  Just a thought. 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Elena Zannoni]

Fernando Nasser writes:
 > Elena Zannoni wrote:
 > > 
 > > Fernando Nasser writes:
 > >  > Hi Stan,
 > >  >
 > >  > Thanks for your comments.
 > >  >
 > >  > Stan Shebs wrote:
 > >  > >
 > >  > > I can't think of a completely reliable test on binary files.  For
 > >  > > instance, in original a.out, stabs are plain symbols, not in a
 > >  > > distinctly-named section.  You also have the problem of an executable
 > >  > > maybe having libraries compiled with stabs, and main prog with dwarf,
 > >  > > and objdump can't distinguish.
 > >  > >
 > >  >
 > >  > True.
 > >  >
 > >  > I was thinking just in terms of the testsuite.  Most test programs are
 > >  > a single file.  Could we test just the object file for that one?
 > > 
 > > I have seen cases in which we have both a .mdebug and a .stabs (or was
 > > that dwarf2) sections (for the same program segment), and even gdb
 > > itself gets confused as to which one is the reliable debug
 > > info. Frankly I wouldn't be able to say exactly under which
 > > circumstances you get this, but I have seen it.
 > > 
 > > I think this is basically what Stan is saying, the heuristic is
 > > unreliable.
 > > 
 > 
 > When you mean that gdb itself gets confused what is the end result of
 > that?
 > Does it pick one at the end (after a warning or something)?

No warning. For instance I have seen it pick the mdebug info which is
incomplete/incorrect. I have looked back at some old mail, and it was
with mdebug and dwarf2. I'll see if I can figure out what was
happening.

 > 
 > Another question: does it happen even with the simple testsuite
 > programs?
 > 

Don't know. I would think so. If the compiler emits 2 types of debug
info, it, in theory, should behave the same with any program.

 > If it is that unreliable, we could make sure the tests run with dwarf
 > only
 > when we are sure it is there and skip when we are not sure (if we can
 > determine that we are not sure from some gdb warning message).
 > 

It would be probably reliable 'in general'. Probably not that many
platforms emit both mdebug & dwarf2.

 > P.S.: We can also be more aggressive and try and see where gdb gets
 > confused
 > and thinks it is dwarf (and so fail the tests).  We could dig for the
 > reason
 > that happens.  Just a thought. 
 > 
 > 

Yep.

Elena

 > -- 
 > Fernando Nasser
 > Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
 > 2323 Yonge Street, Suite #300
 > Toronto, Ontario   M4P 2C9

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Michael Snyder]

Fernando Nasser wrote:
> 
> Hi Stan,
> 
> Thanks for your comments.
> 
> Stan Shebs wrote:
> >
> > I can't think of a completely reliable test on binary files.  For
> > instance, in original a.out, stabs are plain symbols, not in a
> > distinctly-named section.  You also have the problem of an executable
> > maybe having libraries compiled with stabs, and main prog with dwarf,
> > and objdump can't distinguish.
> >
> 
> True.
> 
> I was thinking just in terms of the testsuite.  Most test programs are
> a single file.  Could we test just the object file for that one?
> 
> Another idea: if we can't say t is stabs but we can say it is dwarf,
> we could implement a gdb_is_dwarf instead.  Would that help?

The "info source" command will give you that information.
Haven't tried it with AOUT, but it works with stabs/elf and 
dwarf/elf.  If we got a positive for dwarf we could run the test.

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Fernando Nasser]

Michael Snyder wrote:
> 
> Fernando Nasser wrote:
> >
> > Hi Stan,
> >
> > Thanks for your comments.
> >
> > Stan Shebs wrote:
> > >
> > > I can't think of a completely reliable test on binary files.  For
> > > instance, in original a.out, stabs are plain symbols, not in a
> > > distinctly-named section.  You also have the problem of an executable
> > > maybe having libraries compiled with stabs, and main prog with dwarf,
> > > and objdump can't distinguish.
> > >
> >
> > True.
> >
> > I was thinking just in terms of the testsuite.  Most test programs are
> > a single file.  Could we test just the object file for that one?
> >
> > Another idea: if we can't say t is stabs but we can say it is dwarf,
> > we could implement a gdb_is_dwarf instead.  Would that help?
> 
> The "info source" command will give you that information.
> Haven't tried it with AOUT, but it works with stabs/elf and
> dwarf/elf.  If we got a positive for dwarf we could run the test.

Thanks Michael.  That is really good news.

Please see my comments to Elena's message.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Stabs or Dwarf Was: [PATCH]: testsuite/gdb.base/constvars.exp

[Fernando Nasser]

Well, Jim Blandy pointed out that there is already a get_debug_format
(it is used in ptype.exp, list.exp and in half a dozen of the C++ test
files).

It uses the "info source" command that Michael mentioned (so it is as
reliable
as "info source" is).


For convenience, there is also a setup_xfail_format that causes the
following
test to fail if the debug format is the one specified.  As Michael
Snyder
pointed out in another list, we actually have concluded that we should
do the
opposite: xfail if _not_ the specified format ;-)  Anyway, it is simple
to
test for DWARF2 or any other that we know we can detect more reliably
and that
can accommodate the tests and xfail for all the others.


Thanks to all for the suggestions.


Here is the code for the function:

global debug_format
set debug_format "unknown"

# Run the gdb command "info source" and extract the debugging format
# information from the output and save it in debug_format.

proc get_debug_format { } {
    global gdb_prompt
    global verbose
    global expect_out
    global debug_format

    set debug_format "unknown"
    send_gdb "info source\n"
    gdb_expect 10 {
        -re "Compiled with (.*) debugging format.\r\n$gdb_prompt $" {
            set debug_format $expect_out(1,string)
            verbose "debug format is $debug_format"
            return 1;
        }
        -re "No current source file.\r\n$gdb_prompt $" {
            perror "get_debug_format used when no current source file"
            return 0;
        }
        -re "$gdb_prompt $" {
            warning "couldn't check debug format (no valid response)."
            return 1;
        }
        timeout {
            warning "couldn't check debug format (timed out)."
            return 1;
        }
    }
}

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9