Sourceware infrastructure updates Q1 2023
Sourceware infrastructure community updates for Q1 2023. = New cgit setup gitweb has been working out pretty nicely for many years, but cgit is cgit is nicer looking, has easier to understand URLs and is much faster. The first experimental setup can be found here: https://cygwin.com/cgit/ https://gcc.gnu.org/cgit/ https://sourceware.org/cgit/ Thanks to Jon Turney for the cygwin work. If this works out, we would like to deploy a script written by Arsen Arsenović to switch the main /git/ to cgit while keeping all old gitweb URLs working. See https://sourceware.org/bugzilla/show_bug.cgi?id=29769 = New sparc builder for builder.sourceware.org Thanks to the Gentoo Foundation and OSUOSL [*] there is now a large (and small) gentoo-sparc worker: https://builder.sourceware.org/buildbot/#/workers/35 https://builder.sourceware.org/buildbot/#/workers/36 Please contact the buildbot mailinglis if you want to do specific builds on it: https://sourceware.org/mailman/listinfo/buildbot = AI comes to the bunsen test results It isn't a large language model chatbot, but probably more useful. https://builder.sourceware.org/testruns/ will now predict what it believes the the dejagnu test results should be. It will give a score for what it expected a result to be. e.g for a new FAIL it could say: mispredicted PASS 81% which means in 81% of similar test runs that test PASSed. So you can concentrate on those FAILing tests that have a high PASSing score. For more info see: https://inbox.sourceware.org/buildbot/20230206160507.ga31...@redhat.com/ = openssh update produces misleading invalid key length warning Connecting to sourceware through ssh with a newer openssh or crypto policy might produce a misleading warning about the key length being too short: Bad server host key: Invalid key length Please don't try to replace your ssh key, there is nothing wrong with it. The issue is that you might have an old server key in your ~/.ssh/known_hosts file. Simply remove it and reconnect to get the new server key: ssh-keygen -R sourceware.org ssh-keygen -R cygwin.com ssh-keygen -R gcc.gnu.org See also https://bugzilla.redhat.com/show_bug.cgi?id=2164016 = inbox.sourceware.org and '/' in Message-ID Those using public-inbox might have noticed that when a Message-ID contains a slash character '/' it is not always correctly encoded or decoded as %2F in the inbox.sourceware.org path URLs. If you are using a newer mutt as email client then you might want to make sure that your Message-ID doesn't contain any characters that might need URL encoding. For mutt 2.2 you might want to set the following in your ~/.muttrc to produce a uuid-like Message-ID as other email clients do: set message_id_format="<%x%x%x%x-%x%x-%x%x-%x%x-%x%x%x%x%x%x@%f>" For older mutt, and some more background, see: https://people.kernel.org/monsieuricon/fix-your-mutt = Happy hacking And as always please feel free join the overseers mailinglist https://sourceware.org/mailman/listinfo/overseers file infrastructure issues in bugzilla https://sourceware.org/bugzilla/describecomponents.cgi?product=sourceware or join us in #overseers on irc.libera.chat [*] But specifically Sam James. We should also thank the following other individuals and organisations for maintaining and/or providing hardware for builder.sourceware.org Brno University, Dan Horák, Marist University, Thomas Fitzsimmons, Mark Wielaard, Frank Eigler, IBM, Carl Love, The Works on Arm initiative, Christophe Lyon, and Red Hat
Re: [PATCH v3] strip: keep .ctf section in stripped file
On 7 Mar 2023, Mark Wielaard said: > Hi Nick, Hi Guillermo, > > On Sat, 2023-03-04 at 08:00 -0600, Guillermo E. Martinez wrote: >> Hello, >> >> On Fri, Mar 03, 2023 at 12:24:19PM +, Nick Clifton wrote: >> > Hi Mark, >> > >> > > > > I am mainly wondering why binutils strip already seems to keep ".ctf" >> > > > > sections (even without -g). >> > >> > > Right. But I am wondering how that mechanism works with binutils strip. >> > > Apparently we do something different in eu-strip which makes it >> > > necessary to add a --keep-ctf option based on the section name. It >> > > would be good if we figured out how/what we can do to keep the >> > > different strip utilities in sync. >> > >> > I think that the function that does this is "is_strip_section_1" in >> >> That's right, this function decided whether the section will be striped >> out by default, if it has set `SEC_DEBUGGING' in BFD section flags then >> section is removed by the default. For `.ctf' this flag is not set >> because in `_bfd_elf_make_section_from_shdr' when BFD sections are >> building it uses the section's name: ".debug", ".gnu.debuglto_.debug_", >> ".gnu.linkonce.wi.", ".zdebug", "lines", ".stab", etc, to set >> `SEC_DEBUGGING' flag. >> >> > binutils/objcopy.c. If an input section has the BSF_DEBUGGING flag >> > set (an internal flag to he BFD library, but basically it should be >> > set for all debug sections, including .ctf sections I think), then >> > the basic decision is to keep the section unless -g is used. > > OK, that is interesting. So given the .ctf section is NOT marked as > SEC_DEBUGGING binutils strip basically never strips it. Can I chime in? This behaviour is in line with the intended purpose of CTF, which is to give C programs introspection into into their type systems at all times, via libctf, so we can use it for ABI checking, shared library interface construction at runtime (for dlopen()) and things like that. This is why keeping CTF small is basically our sole format priority: if it's big, people will be tempted to strip it out, and the format becomes useless. (This is also why it's not loadable -- libctf reads it itself so that it doesn't cost time paging it in if it's not used.) (This is also why libctf doesn't follow gnu_debuglink pointers: it can only read CTF from the ELF object itself.) > While eu-strip does strip it by default (since it is a non-loadable > PROGBITS section), but keeps it with -g (which only strips the > explicitly named .debug sections). It should probably keep it regardless, unless you do some sort of "really brutal strip" that strips out literally everything not needed for the program to start at all. It might well be necessary at runtime (in future, anyway). > So binutils strip and eu-strip aren't totally identical with the > default flags, but with --keep-section=.ctf and --remove-section=.ctf > they seem to do the same thing. Yeah, this is a bug -- I simply forgot that eu-strip existed :/ sorry! > So I am not sure we really need a --keep-ctf flag for eu-strip (unless > we also get it for binutils strip). My preference would be to just > recommend a user use --keep-section=.ctf or --remove-section=.ctf to > indicate what they want. My strong preference would be to make eu-strip do what binutils strip does. If CTF is not in the binary, the whole format is useless. If you've got room for the DWARF, the CTF is a strict subset of it anyway (it's generated from it, after all). -- NULL && (void)
