From: Mark Wielaard <mark@klomp.org>
To: Nick Clifton <nickc@redhat.com>
Cc: annobin@sourceware.org
Subject: Re: ☠ Buildbot (Sourceware): annobin - failed test (failure) (master)
Date: Thu, 7 Mar 2024 01:05:24 +0100 [thread overview]
Message-ID: <20240307000524.GF24213@gnu.wildebeest.org> (raw)
In-Reply-To: <d4ea3fa4-8131-46d9-8d04-939cc2195eb9@redhat.com>
Hi Nick,
On Wed, Mar 06, 2024 at 10:45:53AM +0000, Nick Clifton wrote:
> >But in general the debian based builds fail because of the configure
> >check for the clang++ include file failing.
>
> Ah - because it is looking in /usr/include and not `llvm-config --includedir`
>
> I am not sure how to resolve this. The AC_CHECK_HEADER macro does not allow
> for searching in non-standard locations.
>
> Maybe it would be simpler to just delete this check ?
Maybe indeed. I tried and couldn't make it work. AC_CHECK_HEADER seems
to ignore things like CFLAGS, so you might have to do it using
AC_COMPILE_IFELSE and setting CXXFLAGS based on llvm-config
--cflags. But maybe that is too much work. Checking whether
llvm-config is installed might be good though.
> >And the fedora based builds fail because of a MAYB lto FAIL for the
> >debuginfod testcase.
>
> Right. I have tracked this down to the fact that the new code you
> suggested for loading potentially reloc encumbered binary files:
>
> Dwfl *dwfl = dwfl_begin (&dwfl_callbacks);
> Dwfl_Module *module = dwfl_report_elf (dwfl, data->full_filename, data->full_filename, -1, 0, false);
>
> if (module != NULL)
> {
> Dwarf_Addr bias;
> dwarf = dwfl_module_getdwarf (module, &bias);
> }
>
> Appears to automatically follow debug links, using debuginfod if necessary.
> So this means that annocheck no longer reports "I am contacting the
> debuginfod server to see if it has the debug info" and so the debuginfod
> test fails. :-)
ah, yes, sorry about that. libdwfl tries to be really, really
helpful. It goes out of its way to find a matching Dwarf.
> I will update the test so that it checks to see if the debug information
> was silently located.
Looks like most things are green now:
https://builder.sourceware.org/buildbot/#/builders?tags=annobin
Except for debian-i386 and ubuntu-riscv.
debian-i386 fails with:
clang -fplugin=/home/mark/annobin/clang-plugin/annobin-for-clang.so -D_FORTIFY_SOURCE=2 -O2 -g -grecord-gcc-switches -fPIE -Wall -fsanitize=safe-stack -fstack-protector-strong -fsanitize=cfi-cast-strict -c ./hello.c
readelf --wide --notes hello.o > clang-plugin-test.readelf.out
make[1]: *** [Makefile:71: check] Error 1
Which seems to be the "running on clang version" thing.
And that is because Debian inserts Debian :)
$ cat ./clang-plugin/clang-plugin-test.readelf.out
Displaying notes found in: .gnu.build.attributes
Owner Data size Description
GA$<version>3L1244 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA$<tool>running on Debian clang version 14.0.6 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA$<tool>annobin built by clang version 14.0.6 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*cf_protection:0x1 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*GOW:0x20400 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*SpecLoadHarden:0x1 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*<stack prot>all 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*sanitize_safe_stack:0x1 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*sanitize_cfi:0x1 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
GA*<PIC>PIE 0x00000008 OPEN Applies to region from 0 to 0x3 (.L.str)
grepping for "running on .*clang version" makes all tests PASS.
on riscv-ubuntu things fail during the build:
/usr/bin/ld: /usr/lib/llvm-16/bin/../lib/LLVMgold.so: error loading plugin: /usr/lib/llvm-16/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:33: annobin-for-clang.so] Error 1
I think that is because llvm-16-linker-tools isn't installed on the
riscv builders. I will try to install those tomorrow.
Cheers,
Mark
next prev parent reply other threads:[~2024-03-07 0:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 19:22 builder
2024-03-05 21:05 ` Mark Wielaard
2024-03-06 10:45 ` Nick Clifton
2024-03-07 0:05 ` Mark Wielaard [this message]
2024-03-07 13:34 ` ubuntu-riscv " Mark Wielaard
2024-03-08 15:28 ` Nick Clifton
2024-03-08 17:19 ` Mark Wielaard
2024-03-25 17:20 builder
2024-03-25 17:35 builder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240307000524.GF24213@gnu.wildebeest.org \
--to=mark@klomp.org \
--cc=annobin@sourceware.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).