public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Nicholas Vinson <nvinson234@gmail.com>
Cc: binutils@sourceware.org, Sam James <sam@gentoo.org>
Subject: Re: [PATCH 2/3] libctf: Add comment for conditionally def'd sym
Date: Mon, 04 Mar 2024 13:57:09 +0000	[thread overview]
Message-ID: <87wmqije16.fsf@esperi.org.uk> (raw)
In-Reply-To: <ea5ab8fd-256c-4851-977d-963c0f7bdd11@gmail.com> (Nicholas Vinson's message of "Sun, 3 Mar 2024 10:56:11 -0500")

On 3 Mar 2024, Nicholas Vinson said:

> On 3/3/24 10:10, Nick Alcock wrote:
>> On 2 Mar 2024, Nicholas Vinson uttered the following:
>> 
>>> diff --git a/libctf/configure.ac b/libctf/configure.ac
>>> index e4e430615bd..0494a537e78 100644
>>> --- a/libctf/configure.ac
>>> +++ b/libctf/configure.ac
>>> @@ -258,7 +258,8 @@ AC_CACHE_CHECK([for linker versioning flags], [ac_cv_libctf_version_script],
>>>      CFLAGS="$CFLAGS -fPIC"
>>>      AC_LINK_IFELSE([AC_LANG_SOURCE([[int ctf_foo (void) { return 0; }
>>>   				    int main (void) { return ctf_foo(); }]])],
>>> -		  [ac_cv_libctf_version_script="-Wl,--version-script='$srcdir/libctf.ver'"],
>>> +		  [ac_cv_libctf_version_script="-Wl,--version-script"
>>> +		   decommented_version_script=t],
>>>   		  [])
>>>      LDFLAGS="$old_LDFLAGS"
>> Not quite. The stanza you changed there is meant for GNU ld, which
>> supports both undefined symbols in version scripts and /* comments */
>> and needs none of this hackery.
>> We have a three-case case statement here, with the final last-ditch
>> attempt being -export-symbols-regex=, and we need to add another case
>> for "no -B local, doesn't like nonexistent symbols, supports
>> --version-script".
>
> The three cases are not fully independent. The first case defines conftest.ver and conftest.c in such a way that when the test is
> run both ld.bfd and ld.lld pass. As a result, ac_cv_libctf_version_script is set.

Yep.

> Then the next check is if ac_cv_libctf_version_script is empty. It's not, so the check with '-Wl,-B,local' is never run.

That's why I added 'nonexistent' to the version script at that point, to
ensure that if the linker objects to nonexistent symbols in the version
script, we fail that test, leaving ac_cv_libctf_version_script unset. So
the recent-lld setup fails that, cascades into the Solaris version,
fails that, then hits the next case, freshly added, and passes it.

> Even though ld.bfd allows undefined symbols in the symbol version map,
> I believe it excludes them in the libctf symbol table. If that's
> correct, then I request this change be reconsidered because it's a
> much simpler change that supports both ld.bfd and ld.lld.

The *test* is simpler, but it expands use of the horrendous hack which
involves sed-transforming the version script. I was trying to minimize
the number of cases in which we have to use that... but I guess if it's
increasingly a lost cause to do so we could move to doing the
sed-transformation everywhere that supports version scripts at all. It
would certainly simplify things a bit (though not completely simplify
this away, since Solaris still needs different flags as well).

>> Something like the below, perhaps. (Caveat: when I test with LLVM 17 and
>> LDFLAGS="-fuse-ld=lld -Wl,--no-undefined-version" there is no failure to
>> link libctf with trunk binutils, though ld building does fail:
>> ld.lld: error: undefined symbol: ldlex_backup
>>>>> referenced by ldgram.y:860 (../../ld/ldgram.y:860)
>>>>>                ldgram.o:(yyparse)
>>>>> referenced by ldgram.y:1125 (../../ld/ldgram.y:1125)
>>>>>                ldgram.o:(yyparse)
>>>>> referenced by ldgram.y:1146 (../../ld/ldgram.y:1146)
>>>>>                ldgram.o:(yyparse)
>>>>> referenced 1 more times
>> ld.lld: error: undefined symbol: ldlex_wild
>> so this is not really tested and all I can really say is that clang and
>> lld are still happy to link. Don't trust what I wrote here, please test
>> it out -- and obviously it still needs things like the removal of the
>> ctf_label_set symbols that genuinely don't exist, as well. That patch is
>> fine.)
>
> I haven't seen that issue and I've been testing with clang and ld.lld this entire time.
>
> I wonder if this is caused by flex/bison (or lex/yacc). For the record,
> I'm using flex-2.6.4 (Gentoo revision r6) and bison-3.8.2 (Gentoo revision r2).

flex 2.6.4-57 here, but otherwise identical. ldlex_backup is of course a
symbol in ld, and is definitely defined, as is ldlex_wild. Weird.

This is with LLVM 17.0.6 (release, from git).

-- 
NULL && (void)

  reply	other threads:[~2024-03-04 13:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-02  4:59 [PATCH 0/3] Fix ld.lld-17 libctf version script symbol not defined errors Nicholas Vinson
2024-03-02  4:59 ` [PATCH 1/3] libctf: Remove undefined functions from ver. map Nicholas Vinson
2024-04-17 17:58   ` Nick Alcock
2024-03-02  5:00 ` [PATCH 2/3] libctf: Add comment for conditionally def'd sym Nicholas Vinson
2024-03-03 15:10   ` Nick Alcock
2024-03-03 15:56     ` Nicholas Vinson
2024-03-04 13:57       ` Nick Alcock [this message]
2024-03-05  0:37         ` Nicholas Vinson
2024-03-11 15:33           ` Nick Alcock
2024-03-02  5:00 ` [PATCH 3/3] libctf: Regnerate configure Nicholas Vinson

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=87wmqije16.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=nvinson234@gmail.com \
    --cc=sam@gentoo.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).