[PATCH] Update testsuite mechanism to allow object files as source files.

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Update testsuite mechanism to allow object files as source files.

Sourceware - gdb-patches mailing list
Since this patch will be resulting in something of a policy change, I
expect there will be a fair
amount of discussion around it.

High level summary:
In some (hopefully rare) cases, certain tests MUST be built with a
particular compiler to work.  If that compiler is not GCC, then it
makes it very burdensome for developers to run the GDB testsuite and
test those tests.  This change allows those tests to use object files
(generated by the required compiler) as the test source file, so that
when the test suite is run with GCC those tests will still
execute/test properly.

Details:
This change is motivated by the fact that clang and GCC sometimes generate
different output, which affects whether or not a test works properly.  The
particular motivating example is the gdb.dwarf2/dw5-rnglist-test.exp test,
which tests whether or not GDB is properly reading/handling DWARF v5
DW_AT_ranges of the form DW_FORM_rnglistx in lexical block dies.  GCC does
not generate that code, so compiling the test with GCC does not successfully
test anything. Clang does generate that code, so the only way to properly
test this is to compile the test case with clang.  A further twist is that
the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
they start their file index at 0 instead of 1, and the GNU assembler has not
been updated to handle this.  This is not a problem for
assembly files generated by GCC, because GCC generates DWARF v3
.debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
clang-generated .s file for the test is not an option, because the GNU
assembler chokes on it.

This patch updates lib/gdb.exp to allow it to properly handle test
cases where the source file is in fact an object file, and it updates
the dw5-rnglist-test to use an object file rather than the .cc file.  This
in turn makes the test itself compiler-agnostic.


-- Caroline Tice
[hidden email]

gdb/testsuite/ChangeLog

2020-07-16  Caroline Tice  <[hidden email]>

        * lib/gdb.exp (build_executable_from_specs): Create output_dir
        variable from call to standard_output_file; update code that
        compiles source files to object files and copies them to output
        directory, to check first and make sure they are not already
        object file.  If they are already object files, just copy them to
        output directory.
        * gdb.dwarf2/dw5-rnglist-test.o: New file (object file)
        * gdb.dwarf2/dw5-rnglist-test.exp: Update to use .o file rather than
        .cc file; this removes the dependency of this test on clang and
        allows it to work with GCC as well.

v1-0001-Update-GDB-testsuite-to-allow-tests-to-use-pre-bu.patch (56K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Andrew Burgess
* Caroline Tice via Gdb-patches <[hidden email]> [2020-07-16 09:50:36 -0700]:

> Since this patch will be resulting in something of a policy change, I
> expect there will be a fair
> amount of discussion around it.
>
> High level summary:
> In some (hopefully rare) cases, certain tests MUST be built with a
> particular compiler to work.  If that compiler is not GCC, then it
> makes it very burdensome for developers to run the GDB testsuite and
> test those tests.  This change allows those tests to use object files
> (generated by the required compiler) as the test source file, so that
> when the test suite is run with GCC those tests will still
> execute/test properly.
>
> Details:
> This change is motivated by the fact that clang and GCC sometimes generate
> different output, which affects whether or not a test works properly.  The
> particular motivating example is the gdb.dwarf2/dw5-rnglist-test.exp test,
> which tests whether or not GDB is properly reading/handling DWARF v5
> DW_AT_ranges of the form DW_FORM_rnglistx in lexical block dies.  GCC does
> not generate that code, so compiling the test with GCC does not successfully
> test anything. Clang does generate that code, so the only way to properly
> test this is to compile the test case with clang.  A further twist is that
> the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> they start their file index at 0 instead of 1, and the GNU assembler has not
> been updated to handle this.  This is not a problem for
> assembly files generated by GCC, because GCC generates DWARF v3
> .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> clang-generated .s file for the test is not an option, because the GNU
> assembler chokes on it.
>
> This patch updates lib/gdb.exp to allow it to properly handle test
> cases where the source file is in fact an object file, and it updates
> the dw5-rnglist-test to use an object file rather than the .cc file.  This
> in turn makes the test itself compiler-agnostic.

I haven't looked at this particular test, but I think any
justification for this change, especially when the example you cite is
about different DWARF, should include an explanation about why the
existing DWARF assembler can't be used in this case.

Thanks,
Andrew

>
>
> -- Caroline Tice
> [hidden email]
>
> gdb/testsuite/ChangeLog
>
> 2020-07-16  Caroline Tice  <[hidden email]>
>
>         * lib/gdb.exp (build_executable_from_specs): Create output_dir
>         variable from call to standard_output_file; update code that
>         compiles source files to object files and copies them to output
>         directory, to check first and make sure they are not already
>         object file.  If they are already object files, just copy them to
>         output directory.
>         * gdb.dwarf2/dw5-rnglist-test.o: New file (object file)
>         * gdb.dwarf2/dw5-rnglist-test.exp: Update to use .o file rather than
>         .cc file; this removes the dependency of this test on clang and
>         allows it to work with GCC as well.


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Joseph Myers
In reply to this post by Sourceware - gdb-patches mailing list
On Thu, 16 Jul 2020, Caroline Tice via Gdb-patches wrote:

> High level summary:
> In some (hopefully rare) cases, certain tests MUST be built with a
> particular compiler to work.  If that compiler is not GCC, then it
> makes it very burdensome for developers to run the GDB testsuite and
> test those tests.  This change allows those tests to use object files
> (generated by the required compiler) as the test source file, so that
> when the test suite is run with GCC those tests will still
> execute/test properly.

How is this expected to work when the GDB being tested is configured for a
different architecture or OS from that of the checked-in object file and
may not be able to read its object file format at all?  Will all such
tests have explicit conditioning on the target for which GDB is
configured?

On general free software and reproducible builds principles:

* The source for any checked-in object file should be checked in.

* That source should include comments giving all information required to
be able to reproduce the object file byte-for-byte - for example, the
exact git commit of the compiler used to generate it, the exact options
with which that compiler should be configured and the exact command line
to use with that compiler to generate that object file.  And it should
have been verified by someone in a different environment from the person
proposing the addition of such an object file that following those
instructions does give a byte-for-byte identical object file.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Sourceware - gdb-patches mailing list
In reply to this post by Andrew Burgess
This text, extracted from my detailed explanation, DOES explain (I
thought) why the existing DWARF assembler can't be used:

> > A further twist is that
> > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> > they start their file index at 0 instead of 1, and the GNU assembler has not
> > been updated to handle this.  This is not a problem for
> > assembly files generated by GCC, because GCC generates DWARF v3
> > .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> > clang-generated .s file for the test is not an option, because the GNU
> > assembler chokes on it.

-- Caroline
[hidden email]

On Thu, Jul 16, 2020 at 10:21 AM Andrew Burgess
<[hidden email]> wrote:

>
> * Caroline Tice via Gdb-patches <[hidden email]> [2020-07-16 09:50:36 -0700]:
>
> > Since this patch will be resulting in something of a policy change, I
> > expect there will be a fair
> > amount of discussion around it.
> >
> > High level summary:
> > In some (hopefully rare) cases, certain tests MUST be built with a
> > particular compiler to work.  If that compiler is not GCC, then it
> > makes it very burdensome for developers to run the GDB testsuite and
> > test those tests.  This change allows those tests to use object files
> > (generated by the required compiler) as the test source file, so that
> > when the test suite is run with GCC those tests will still
> > execute/test properly.
> >
> > Details:
> > This change is motivated by the fact that clang and GCC sometimes generate
> > different output, which affects whether or not a test works properly.  The
> > particular motivating example is the gdb.dwarf2/dw5-rnglist-test.exp test,
> > which tests whether or not GDB is properly reading/handling DWARF v5
> > DW_AT_ranges of the form DW_FORM_rnglistx in lexical block dies.  GCC does
> > not generate that code, so compiling the test with GCC does not successfully
> > test anything. Clang does generate that code, so the only way to properly
> > test this is to compile the test case with clang.  A further twist is that
> > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> > they start their file index at 0 instead of 1, and the GNU assembler has not
> > been updated to handle this.  This is not a problem for
> > assembly files generated by GCC, because GCC generates DWARF v3
> > .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> > clang-generated .s file for the test is not an option, because the GNU
> > assembler chokes on it.
> >
> > This patch updates lib/gdb.exp to allow it to properly handle test
> > cases where the source file is in fact an object file, and it updates
> > the dw5-rnglist-test to use an object file rather than the .cc file.  This
> > in turn makes the test itself compiler-agnostic.
>
> I haven't looked at this particular test, but I think any
> justification for this change, especially when the example you cite is
> about different DWARF, should include an explanation about why the
> existing DWARF assembler can't be used in this case.
>
> Thanks,
> Andrew
>
> >
> >
> > -- Caroline Tice
> > [hidden email]
> >
> > gdb/testsuite/ChangeLog
> >
> > 2020-07-16  Caroline Tice  <[hidden email]>
> >
> >         * lib/gdb.exp (build_executable_from_specs): Create output_dir
> >         variable from call to standard_output_file; update code that
> >         compiles source files to object files and copies them to output
> >         directory, to check first and make sure they are not already
> >         object file.  If they are already object files, just copy them to
> >         output directory.
> >         * gdb.dwarf2/dw5-rnglist-test.o: New file (object file)
> >         * gdb.dwarf2/dw5-rnglist-test.exp: Update to use .o file rather than
> >         .cc file; this removes the dependency of this test on clang and
> >         allows it to work with GCC as well.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Sourceware - gdb-patches mailing list
In reply to this post by Joseph Myers
On Thu, Jul 16, 2020 at 10:33 AM Joseph Myers <[hidden email]> wrote:

>
> On Thu, 16 Jul 2020, Caroline Tice via Gdb-patches wrote:
>
> > High level summary:
> > In some (hopefully rare) cases, certain tests MUST be built with a
> > particular compiler to work.  If that compiler is not GCC, then it
> > makes it very burdensome for developers to run the GDB testsuite and
> > test those tests.  This change allows those tests to use object files
> > (generated by the required compiler) as the test source file, so that
> > when the test suite is run with GCC those tests will still
> > execute/test properly.
>
> How is this expected to work when the GDB being tested is configured for a
> different architecture or OS from that of the checked-in object file and
> may not be able to read its object file format at all?  Will all such
> tests have explicit conditioning on the target for which GDB is
> configured?

That is a very good point; I suppose this test should be marked to
only work on the architecture for which the test was compiled? (I know
I've seen those kinds of restrictions in testsuites before, although
I'm not sure if the GDB testsuite is currently set up for such
restrictions).

>
> On general free software and reproducible builds principles:
>
> * The source for any checked-in object file should be checked in.
>
> * That source should include comments giving all information required to
> be able to reproduce the object file byte-for-byte - for example, the
> exact git commit of the compiler used to generate it, the exact options
> with which that compiler should be configured and the exact command line
> to use with that compiler to generate that object file.  And it should
> have been verified by someone in a different environment from the person
> proposing the addition of such an object file that following those
> instructions does give a byte-for-byte identical object file.

The source code for this test case was checked in as part of the patch
recently committed for fixing GDB's handling of DWARF v5 dwo files.
The
source file is in gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.cc

The command used to generate the .object file is added in the comments
of the updated testcase in the patch I attached to the first message
in this thread (in the file
gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.exp.  I did not include the
compiler version information in those comments, but I can certainly
update it to do so.

>
> --
> Joseph S. Myers
> [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Andrew Burgess
In reply to this post by Sourceware - gdb-patches mailing list
* Caroline Tice <[hidden email]> [2020-07-16 11:07:39 -0700]:

> This text, extracted from my detailed explanation, DOES explain (I
> thought) why the existing DWARF assembler can't be used:
>
> > > A further twist is that
> > > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> > > they start their file index at 0 instead of 1, and the GNU assembler has not
> > > been updated to handle this.  This is not a problem for
> > > assembly files generated by GCC, because GCC generates DWARF v3
> > > .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> > > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> > > clang-generated .s file for the test is not an option, because the GNU
> > > assembler chokes on it.

But GDB's DWARF assembler (gdb/testsuite/lib/dwarf.exp) just generates
.byte/.word/etc?  I don't see why there would be any problems
extending this to cover the features you'd want (again, I say this
without actually looking at your example test).  It seems like the
text above would apply to the GNU assembler trying to assemble .file
directives as generated by a compiler.

Also, on further reflection, we already have tests like:
  gdb/testsuite/gdb.arch/amd64-entry-value-param-dwarf5.S
where the DWARF has been compiled down to a raw assembler file.  Given
that, as has already been pointed out, any object file is going to be
architecture and maybe even OS specific anyway, there doesn't appear
to be much (any?) difference between adding object files into the
testsuite and just adding the test as a raw assembler file.  Have you
considered this approach?

Thanks,
Andrew





>
> -- Caroline
> [hidden email]
>
> On Thu, Jul 16, 2020 at 10:21 AM Andrew Burgess
> <[hidden email]> wrote:
> >
> > * Caroline Tice via Gdb-patches <[hidden email]> [2020-07-16 09:50:36 -0700]:
> >
> > > Since this patch will be resulting in something of a policy change, I
> > > expect there will be a fair
> > > amount of discussion around it.
> > >
> > > High level summary:
> > > In some (hopefully rare) cases, certain tests MUST be built with a
> > > particular compiler to work.  If that compiler is not GCC, then it
> > > makes it very burdensome for developers to run the GDB testsuite and
> > > test those tests.  This change allows those tests to use object files
> > > (generated by the required compiler) as the test source file, so that
> > > when the test suite is run with GCC those tests will still
> > > execute/test properly.
> > >
> > > Details:
> > > This change is motivated by the fact that clang and GCC sometimes generate
> > > different output, which affects whether or not a test works properly.  The
> > > particular motivating example is the gdb.dwarf2/dw5-rnglist-test.exp test,
> > > which tests whether or not GDB is properly reading/handling DWARF v5
> > > DW_AT_ranges of the form DW_FORM_rnglistx in lexical block dies.  GCC does
> > > not generate that code, so compiling the test with GCC does not successfully
> > > test anything. Clang does generate that code, so the only way to properly
> > > test this is to compile the test case with clang.  A further twist is that
> > > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> > > they start their file index at 0 instead of 1, and the GNU assembler has not
> > > been updated to handle this.  This is not a problem for
> > > assembly files generated by GCC, because GCC generates DWARF v3
> > > .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> > > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> > > clang-generated .s file for the test is not an option, because the GNU
> > > assembler chokes on it.
> > >
> > > This patch updates lib/gdb.exp to allow it to properly handle test
> > > cases where the source file is in fact an object file, and it updates
> > > the dw5-rnglist-test to use an object file rather than the .cc file.  This
> > > in turn makes the test itself compiler-agnostic.
> >
> > I haven't looked at this particular test, but I think any
> > justification for this change, especially when the example you cite is
> > about different DWARF, should include an explanation about why the
> > existing DWARF assembler can't be used in this case.
> >
> > Thanks,
> > Andrew
> >
> > >
> > >
> > > -- Caroline Tice
> > > [hidden email]
> > >
> > > gdb/testsuite/ChangeLog
> > >
> > > 2020-07-16  Caroline Tice  <[hidden email]>
> > >
> > >         * lib/gdb.exp (build_executable_from_specs): Create output_dir
> > >         variable from call to standard_output_file; update code that
> > >         compiles source files to object files and copies them to output
> > >         directory, to check first and make sure they are not already
> > >         object file.  If they are already object files, just copy them to
> > >         output directory.
> > >         * gdb.dwarf2/dw5-rnglist-test.o: New file (object file)
> > >         * gdb.dwarf2/dw5-rnglist-test.exp: Update to use .o file rather than
> > >         .cc file; this removes the dependency of this test on clang and
> > >         allows it to work with GCC as well.
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Andrew Burgess
In reply to this post by Sourceware - gdb-patches mailing list
* Caroline Tice via Gdb-patches <[hidden email]> [2020-07-16 11:13:24 -0700]:

> On Thu, Jul 16, 2020 at 10:33 AM Joseph Myers <[hidden email]> wrote:
> >
> > On Thu, 16 Jul 2020, Caroline Tice via Gdb-patches wrote:
> >
> > > High level summary:
> > > In some (hopefully rare) cases, certain tests MUST be built with a
> > > particular compiler to work.  If that compiler is not GCC, then it
> > > makes it very burdensome for developers to run the GDB testsuite and
> > > test those tests.  This change allows those tests to use object files
> > > (generated by the required compiler) as the test source file, so that
> > > when the test suite is run with GCC those tests will still
> > > execute/test properly.
> >
> > How is this expected to work when the GDB being tested is configured for a
> > different architecture or OS from that of the checked-in object file and
> > may not be able to read its object file format at all?  Will all such
> > tests have explicit conditioning on the target for which GDB is
> > configured?
>
> That is a very good point; I suppose this test should be marked to
> only work on the architecture for which the test was compiled? (I know
> I've seen those kinds of restrictions in testsuites before, although
> I'm not sure if the GDB testsuite is currently set up for such
> restrictions).

Yes tests can be restricted for particular architectures, look for
istarget checks throughout the testsuite, for example in:

  gdb/testsuite/gdb.arch/amd64-entry-value-param-dwarf5.exp

Thanks,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Tom Tromey-2
In reply to this post by Joseph Myers
Joseph> On general free software and reproducible builds principles:
Joseph> * The source for any checked-in object file should be checked in.
Joseph> * That source should include comments giving all information required to
Joseph> be able to reproduce the object file byte-for-byte

In the past we tried this kind of thing, by taking the assembly
generated by the compiler, then editing it and checking it in.

However, IMO, this turned out to be a pain.  The hand editing was often
not sufficiently documented, and the tests were still
architecture-dependent.  Once or twice I think someone has had to edit
the .S file later, which is error-prone.  Also, the earliest test suite
additions like this didn't include the original source, making this
harder to handle.

The "DWARF assembler" in the test suite avoids all this, at least for
tests that require particular debuginfo.  The main drawbacks of this
approach are (again IMO) that sometimes it's a pain to write the DWARF
by hand, and that sometimes the assembler framework itself needs
upgrades before one can even begin.  However, the tests are much more
robust.

I'd encourage the extension of the latter approach as much as possible.
It isn't perfect but IME has been better on the whole.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Joseph Myers
In reply to this post by Sourceware - gdb-patches mailing list
On Thu, 16 Jul 2020, Caroline Tice via Gdb-patches wrote:

> The command used to generate the .object file is added in the comments
> of the updated testcase in the patch I attached to the first message
> in this thread (in the file
> gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.exp.  I did not include the
> compiler version information in those comments, but I can certainly
> update it to do so.

Note that it's best for the compiler for this sort of thing to be an
unmodified upstream version - not a distribution version.  Cf. the issues
we have with people checking in configure scripts generated by
distribution version of autoconf, which are not the same as generated by
upstream autoconf.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Sourceware - gdb-patches mailing list
In reply to this post by Tom Tromey-2
Has the DWARF assembler in the GDB testsuite been updated to handle
DWARF v5?  Or can it handle that automatically?  Is there a good
example I can look at to see how to use it?

-- Caroline
[hidden email]

On Thu, Jul 16, 2020 at 1:12 PM Tom Tromey <[hidden email]> wrote:

>
> Joseph> On general free software and reproducible builds principles:
> Joseph> * The source for any checked-in object file should be checked in.
> Joseph> * That source should include comments giving all information required to
> Joseph> be able to reproduce the object file byte-for-byte
>
> In the past we tried this kind of thing, by taking the assembly
> generated by the compiler, then editing it and checking it in.
>
> However, IMO, this turned out to be a pain.  The hand editing was often
> not sufficiently documented, and the tests were still
> architecture-dependent.  Once or twice I think someone has had to edit
> the .S file later, which is error-prone.  Also, the earliest test suite
> additions like this didn't include the original source, making this
> harder to handle.
>
> The "DWARF assembler" in the test suite avoids all this, at least for
> tests that require particular debuginfo.  The main drawbacks of this
> approach are (again IMO) that sometimes it's a pain to write the DWARF
> by hand, and that sometimes the assembler framework itself needs
> upgrades before one can even begin.  However, the tests are much more
> robust.
>
> I'd encourage the extension of the latter approach as much as possible.
> It isn't perfect but IME has been better on the whole.
>
> Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Sourceware - gdb-patches mailing list
Should be just gas in the binutils-gdb checkout?

-eric

On Thu, Jul 16, 2020 at 2:10 PM Caroline Tice via Gdb-patches <
[hidden email]> wrote:

> Has the DWARF assembler in the GDB testsuite been updated to handle
> DWARF v5?  Or can it handle that automatically?  Is there a good
> example I can look at to see how to use it?
>
> -- Caroline
> [hidden email]
>
> On Thu, Jul 16, 2020 at 1:12 PM Tom Tromey <[hidden email]> wrote:
> >
> > Joseph> On general free software and reproducible builds principles:
> > Joseph> * The source for any checked-in object file should be checked in.
> > Joseph> * That source should include comments giving all information
> required to
> > Joseph> be able to reproduce the object file byte-for-byte
> >
> > In the past we tried this kind of thing, by taking the assembly
> > generated by the compiler, then editing it and checking it in.
> >
> > However, IMO, this turned out to be a pain.  The hand editing was often
> > not sufficiently documented, and the tests were still
> > architecture-dependent.  Once or twice I think someone has had to edit
> > the .S file later, which is error-prone.  Also, the earliest test suite
> > additions like this didn't include the original source, making this
> > harder to handle.
> >
> > The "DWARF assembler" in the test suite avoids all this, at least for
> > tests that require particular debuginfo.  The main drawbacks of this
> > approach are (again IMO) that sometimes it's a pain to write the DWARF
> > by hand, and that sometimes the assembler framework itself needs
> > upgrades before one can even begin.  However, the tests are much more
> > robust.
> >
> > I'd encourage the extension of the latter approach as much as possible.
> > It isn't perfect but IME has been better on the whole.
> >
> > Tom
>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Andrew Burgess
In reply to this post by Sourceware - gdb-patches mailing list
* Caroline Tice via Gdb-patches <[hidden email]> [2020-07-16 14:10:25 -0700]:

> Has the DWARF assembler in the GDB testsuite been updated to handle
> DWARF v5?  Or can it handle that automatically?  Is there a good
> example I can look at to see how to use it?

To find examples look for the pattern 'Dwarf::assemble" in
gdb/testsuite/gdb.dwarf2/*.exp.

The dwarf assembler does use include/dwarf.h and include/dwarf.def to
build up the set of attributes and form types that are supported, so
in that sense the basics of DWARF5 will be supported, but when you
start to look at new sections, or new layouts for existing sections,
then no, this is most likely not supported, yet.

Thanks,
Andrew







>
> -- Caroline
> [hidden email]
>
> On Thu, Jul 16, 2020 at 1:12 PM Tom Tromey <[hidden email]> wrote:
> >
> > Joseph> On general free software and reproducible builds principles:
> > Joseph> * The source for any checked-in object file should be checked in.
> > Joseph> * That source should include comments giving all information required to
> > Joseph> be able to reproduce the object file byte-for-byte
> >
> > In the past we tried this kind of thing, by taking the assembly
> > generated by the compiler, then editing it and checking it in.
> >
> > However, IMO, this turned out to be a pain.  The hand editing was often
> > not sufficiently documented, and the tests were still
> > architecture-dependent.  Once or twice I think someone has had to edit
> > the .S file later, which is error-prone.  Also, the earliest test suite
> > additions like this didn't include the original source, making this
> > harder to handle.
> >
> > The "DWARF assembler" in the test suite avoids all this, at least for
> > tests that require particular debuginfo.  The main drawbacks of this
> > approach are (again IMO) that sometimes it's a pain to write the DWARF
> > by hand, and that sometimes the assembler framework itself needs
> > upgrades before one can even begin.  However, the tests are much more
> > robust.
> >
> > I'd encourage the extension of the latter approach as much as possible.
> > It isn't perfect but IME has been better on the whole.
> >
> > Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Andrew Burgess
In reply to this post by Sourceware - gdb-patches mailing list
* Eric Christopher via Gdb-patches <[hidden email]> [2020-07-16 14:16:46 -0700]:

> Should be just gas in the binutils-gdb checkout?

GDB's DWARF assembler is written in TCL, and generates a .S file
containing the debug sections and their contents.

A test will usually consist of some DWARF written in TCL and a C file.
The C file is compiled without debug information and the TCL code then
places references to symbols in the C file into the generated DWARF.

The DWARF assembler then creates a .S file, which is assembled and
linked with the C file.

We then start up GDB and debug as normal.

Thanks,
Andrew




>
> -eric
>
> On Thu, Jul 16, 2020 at 2:10 PM Caroline Tice via Gdb-patches <
> [hidden email]> wrote:
>
> > Has the DWARF assembler in the GDB testsuite been updated to handle
> > DWARF v5?  Or can it handle that automatically?  Is there a good
> > example I can look at to see how to use it?
> >
> > -- Caroline
> > [hidden email]
> >
> > On Thu, Jul 16, 2020 at 1:12 PM Tom Tromey <[hidden email]> wrote:
> > >
> > > Joseph> On general free software and reproducible builds principles:
> > > Joseph> * The source for any checked-in object file should be checked in.
> > > Joseph> * That source should include comments giving all information
> > required to
> > > Joseph> be able to reproduce the object file byte-for-byte
> > >
> > > In the past we tried this kind of thing, by taking the assembly
> > > generated by the compiler, then editing it and checking it in.
> > >
> > > However, IMO, this turned out to be a pain.  The hand editing was often
> > > not sufficiently documented, and the tests were still
> > > architecture-dependent.  Once or twice I think someone has had to edit
> > > the .S file later, which is error-prone.  Also, the earliest test suite
> > > additions like this didn't include the original source, making this
> > > harder to handle.
> > >
> > > The "DWARF assembler" in the test suite avoids all this, at least for
> > > tests that require particular debuginfo.  The main drawbacks of this
> > > approach are (again IMO) that sometimes it's a pain to write the DWARF
> > > by hand, and that sometimes the assembler framework itself needs
> > > upgrades before one can even begin.  However, the tests are much more
> > > robust.
> > >
> > > I'd encourage the extension of the latter approach as much as possible.
> > > It isn't perfect but IME has been better on the whole.
> > >
> > > Tom
> >
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Sourceware - gdb-patches mailing list
I've been able to generate/hand-edit a .S file for this test (thanks to
various people for help/suggestions).  I will drop this object-file
approach and submit a new patch (on a new thread) with the .S file update.
Thanks everyone!

-- Caroline
[hidden email]


On Fri, Jul 17, 2020 at 2:48 AM Andrew Burgess <[hidden email]>
wrote:

> * Eric Christopher via Gdb-patches <[hidden email]>
> [2020-07-16 14:16:46 -0700]:
>
> > Should be just gas in the binutils-gdb checkout?
>
> GDB's DWARF assembler is written in TCL, and generates a .S file
> containing the debug sections and their contents.
>
> A test will usually consist of some DWARF written in TCL and a C file.
> The C file is compiled without debug information and the TCL code then
> places references to symbols in the C file into the generated DWARF.
>
> The DWARF assembler then creates a .S file, which is assembled and
> linked with the C file.
>
> We then start up GDB and debug as normal.
>
> Thanks,
> Andrew
>
>
>
>
> >
> > -eric
> >
> > On Thu, Jul 16, 2020 at 2:10 PM Caroline Tice via Gdb-patches <
> > [hidden email]> wrote:
> >
> > > Has the DWARF assembler in the GDB testsuite been updated to handle
> > > DWARF v5?  Or can it handle that automatically?  Is there a good
> > > example I can look at to see how to use it?
> > >
> > > -- Caroline
> > > [hidden email]
> > >
> > > On Thu, Jul 16, 2020 at 1:12 PM Tom Tromey <[hidden email]> wrote:
> > > >
> > > > Joseph> On general free software and reproducible builds principles:
> > > > Joseph> * The source for any checked-in object file should be
> checked in.
> > > > Joseph> * That source should include comments giving all information
> > > required to
> > > > Joseph> be able to reproduce the object file byte-for-byte
> > > >
> > > > In the past we tried this kind of thing, by taking the assembly
> > > > generated by the compiler, then editing it and checking it in.
> > > >
> > > > However, IMO, this turned out to be a pain.  The hand editing was
> often
> > > > not sufficiently documented, and the tests were still
> > > > architecture-dependent.  Once or twice I think someone has had to
> edit
> > > > the .S file later, which is error-prone.  Also, the earliest test
> suite
> > > > additions like this didn't include the original source, making this
> > > > harder to handle.
> > > >
> > > > The "DWARF assembler" in the test suite avoids all this, at least for
> > > > tests that require particular debuginfo.  The main drawbacks of this
> > > > approach are (again IMO) that sometimes it's a pain to write the
> DWARF
> > > > by hand, and that sometimes the assembler framework itself needs
> > > > upgrades before one can even begin.  However, the tests are much more
> > > > robust.
> > > >
> > > > I'd encourage the extension of the latter approach as much as
> possible.
> > > > It isn't perfect but IME has been better on the whole.
> > > >
> > > > Tom
> > >
>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update testsuite mechanism to allow object files as source files.

Tom Tromey-2
In reply to this post by Andrew Burgess
>>>>> "Andrew" == Andrew Burgess <[hidden email]> writes:

Andrew> * Caroline Tice via Gdb-patches <[hidden email]> [2020-07-16 14:10:25 -0700]:
>> Has the DWARF assembler in the GDB testsuite been updated to handle
>> DWARF v5?  Or can it handle that automatically?  Is there a good
>> example I can look at to see how to use it?

Andrew> To find examples look for the pattern 'Dwarf::assemble" in
Andrew> gdb/testsuite/gdb.dwarf2/*.exp.

There are also comments in gdb/testsuite/lib/dwarf.exp explaining how to
use it.

Tom