From: Alexander Miller <alex.miller@gmx.de>
To: Mark Wielaard <mark@klomp.org>, elfutils-devel@sourceware.org
Subject: Re: [PATCH] Improve building with LTO
Date: Thu, 18 Feb 2021 15:27:02 +0100 [thread overview]
Message-ID: <20210218152702.18d515ed.alex.miller@gmx.de> (raw)
In-Reply-To: <f595fe47b122f545178ef79a7227f48e2e6f3400.camel@klomp.org>
[Re-sending mail because the list has been omitted by mistake.]
On Wed, 17 Feb 2021 21:22:15 +0100
Mark Wielaard <mark@klomp.org> wrote:
> So you rewrite the asm statements to not use @@@ just @ and @@, that
> way they match the symver attribute usage. Smart, that way they are as
> similar as possible.
Yes, I wanted symbol versioning to work the same way in both cases.
> > I've tested the patch with different compilers (gcc-10, gcc-9, gcc-6,
> > clang-11), linkers (bfd, gold, lld), 32/64 bit (x86), with/without LTO.
> > Of course you need to cheat a bit to build elfutils with clang, and
> > lld can't be used with every combination. The workaround for older gcc
> > was enough for gcc-9 and 32bit gcc-6, but 64bit gcc-6 builds needed
> > -flto-partition=none, so this seems to depend on the version and options
> > used.
>
> Wow, you really went above and beyond. IMHO it would have been fine to
> simply say that you need GCC10 and a recent binutils ld to get LTO
> working. Supporting LTO with gcc-6 is really nice, but people stuck on
> such an old compiler should probably first look at upgrading that than
> trying to play with LTO. We should probably look at making an LTO build
> part of the buildbot.
Of course gcc-6 is really old (I just happened to have it still available).
But getting LTO to work with gcc-9 would be nice. That worked in my tests,
but I'm not sure if it's reliable. And it's only a small addition (and I
didn't add anything more for gcc-6).
But most importantly I didn't want to paint myself into a corner and change
symbol versioning in a way that will only ever work with one particular
toolchain.
> > The test suite seems brittle, though. It fails on 32bit builds, with
> > gold or lld, and with lto builds using clang (unknown object format)
> > or gcc-6 (debug info not found). But that's not related to this patch.
> > For 64bit builds with gcc-{9,10} and bfd, the test suite succeeds even
> > with lto enabled.
>
> Do the 32bit builds with gcc10/binutils ld have a clean test suite?
Only the 64bit builds with bfd passed. For all 32bit builds (64bit system,
but built with -m32) the test case "run-backtrace-native-biarch.sh" fails:
|
| 0x556a53cef000 0x556a53cf4000 .../tests/backtrace-child-biarch
| 0x7fadd8118000 0x7fadd828d000 /lib64/libc-2.32.so
| 0x7fadd8298000 0x7fadd82b4000 /lib64/libpthread-2.32.so
| 0x7fadd82f0000 0x7fadd831d000 /lib64/ld-2.32.so
| 0x7ffdf13fc000 0x7ffdf13fd000 [vdso: 6783]
| TID 6783:
| .../tests/backtrace: dwfl_thread_getframes: no error
| backtrace: linux-pid-attach.c:326: pid_set_initial_registers: Assertion `pid_arg->tid_attached == 0' failed.
| ./test-subr.sh: line 84: 6782 Aborted LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" $VALGRIND_CMD "$@"
| backtrace-child-biarch: no main
| FAIL run-backtrace-native-biarch.sh (exit status: 1)
But that isn't related to my patch. It was the same before.
> > * Commenting out old versions in the .map file may not be needed.
> > It's mostly a leftover from an earlier attempt, but I didn't want to
> > re-run all test and I actually prefer it like this, so I left it in.
>
> I would like to make sure it isn't needed. Having to comment out old
> versions is a bit of a pain.
I've run a few tests and it works without that change. I'll skip that
in the next version of the patch.
(Gold has trouble when a an object defines an unversioned symbol and
the version script contains the old version; that isn't the case in my
solution because the "new" functions get renamed.)
> How does the __COUNTER__ magic work?
It doesn't.
Sorry. I'm adding two levels of indirection to make it work. I didn't
notice since it's not needed at the moment. In the future, somebody
might want to add multiple old versions for a symbol, and then they
need different names.
> I have to stare at the marcos a bit to make sure I really understand
> what is going on. But this looks really good.
Don't hesitate to ask if something isn't clear.
I'll post an updated patch later.
Cheers,
Alex
next prev parent reply other threads:[~2021-02-18 14:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-14 22:57 Alexander Miller
2021-02-17 20:22 ` Mark Wielaard
2021-02-18 14:27 ` Alexander Miller [this message]
2021-02-18 2:38 ` [PATCH v2] " Alexander Miller
2021-08-28 9:31 ` Dmitry V. Levin
2021-11-04 11:23 ` Dmitry V. Levin
2021-11-04 12:12 ` Mark Wielaard
2021-11-08 10:02 ` Dmitry V. Levin
2021-11-08 23:18 ` Mark Wielaard
2021-11-09 8:58 ` Dmitry V. Levin
2021-11-09 9:04 ` Martin Liška
2021-11-09 9:09 ` Dmitry V. Levin
2021-11-09 9:11 ` Martin Liška
2021-11-09 11:45 ` Mark Wielaard
2021-11-09 13:31 ` Martin Liška
2021-11-09 13:33 ` Martin Liška
2021-11-09 17:49 ` Mark Wielaard
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=20210218152702.18d515ed.alex.miller@gmx.de \
--to=alex.miller@gmx.de \
--cc=elfutils-devel@sourceware.org \
--cc=mark@klomp.org \
/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).