Adding binutils to the GNU Toolchain buildbot on sourceware

[Nick Alcock]

On 30 Apr 2022, Mark Wielaard said:

> On Sat, Apr 30, 2022 at 01:12:54AM +0100, Nick Alcock via Overseers wrote:
>> > 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.

Excellent!

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

That seems perfectly reasonable. (ld/ is directly affected, as are
objcopy and objdump.)

>> 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?

Oh definitely. They're both stable and quick.

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

I'd expect everything to both run and pass (and do so quickly) on a
Linux system with GCC 12.

-- 
NULL && (void)