Re: Adding binutils to the GNU Toolchain buildbot on sourceware

[Nick Alcock <nick.alcock@oracle.com>]

On 29 Apr 2022, Mark Wielaard uttered the following:

> Hi Nick,
>
> 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 :)

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

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.

> 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 :)

> Maybe we should add something similar for gprof, gprofng and sim?

gprof doesn't seem to have any tests. I suppoe it might be worth just
making sure changes don't break compilation. gprofng too, but maybe a
litlelater, once the more obvious compilation problems are knocked out
of it. (And definitely run its testsuite. gprofng already has a few
tests and will certainly acquire more with time. Its arch requirements
are fairly tight but x86 is a common arch so probably not actually
*problematic*.)

-- 
NULL && (void)