Re: Adding binutils to the GNU Toolchain buildbot on sourceware

[Mark Wielaard <mark@klomp.org>]

Hi Nick,

On Sat, Apr 30, 2022 at 01:12:54AM +0100, Nick Alcock via Overseers wrote:
> On 29 Apr 2022, Mark Wielaard uttered the following:
> > On Thu, Apr 28, 2022 at 06:50:02PM +0100, Nick Alcock wrote:
> >> On 28 Apr 2022, Luis Machado via Binutils outgrape:
> >> > It would make sense to build-test gdb if any of the following changes:
> >> [...]
> >> > libctf/
> >> 
> >> This won't do much with gdb without a (much) newer compiler. (I
> >> build-test gdb before every libctf commit -- every commit that I do,
> >> anyway. I do actual gdb test runs rather less often. I should fix that,
> >> at least for the CTF tests...)
> >> 
> >> It doesn't change anywhere near as often as GDB though so the cost of
> >> adding it is low.
> >
> > How much newer compiler are we talking? There are other builders that
> > use workers which might have newer gcc installed.
> 
> Oh, quite a lot newer -- CTF support in GCC has been in progress since
> the GCC 10 days, but it only landed in GCC proper after GCC 11 branched,
> so it'll be in GCC 12. It's not in a released GCC yet, but we're
> counting the days :)

OK, and it looks like Fedora 36 will also be released in the next
couple of weeks using GCC12. So once one of the fedora workers is
upgraded to Fedora 36 we can add a new libctf specific builder.

> > A change in libctf is tested against a build of gdb (but no tests
> > yet).  Should a change in libctf also cause a check of a build of
> > gas/ld/binutils/gold and tests of gas/ld/binutils?
> 
> That's probably fairly pointless without GCC 12 in the mix. Even then,
> checking ld and GDB is worthwhile but not the others: gas doesn't depend
> on it at all, gold doesn't have CTF dedup support (yet: I do mean to add
> it), and binutils's objcopy CTF support is only tested by the ld
> testsuite's usage of objcopy.

Even so it seems important to test that everything at least builds
when libctf is changed and that none of the tests fail. Even if there
aren't that many to begin with. I have added libctf/ to the binutils
files for now.

> Also, note that GDB doesn't have very many CTF tests yet: you might want
> to build it but not run the *entire* testsuite, just tests matching
> *ctf*, just to save time, since the GDB testsuite is so huge. Changes to
> the CTF code aren't going to break the rest of GDB (I hope!). Mind you,
> if it *does*, finding that out is exactly what buildbots are for.
> I'm vacillating.

For now we don't have any "stable subset" of gdb tests that we run. If
the ctf-constvars.exp and ctf-ptype.exp are stable (and quick) maybe
they could be part of that stable set?
 
> > Are there any specific ctf tests that aren't part of the above
> > testsuite? If so would it make sense to make libctf its own "project"
> > so that a change to libctf (and any depended directoy/config files)
> > would cause a "just build libctf and run the ctf testsuite"?
> 
> Hm. That's probably a good idea -- most of the libctf tests require a
> compiler supporting -gctf, but there *are* a few that test the writable
> dict API (the same one used by ld to emit CTF after deduplication).
> They're not exactly comprehensive tests (they're checking for write-time
> regressions that are not triggered by ld's usage of libctf) but they do
> cover a surprising percentage of libctf nonetheless. It even tests some
> of the ctf_link API, though not the complicated deduplicating part. And
> libctf does build quickly :)

OK. Lets look at that in a couple of weeks when we have a builder that
can use a GCC12 using distro.

Cheers,

Mark