public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Sam James <sam@gentoo.org>
Cc: Nicholas Vinson <nvinson234@gmail.com>,
	binutils <binutils@sourceware.org>
Subject: Re: [binutils] libctf: Remove undefined functions from ver. map
Date: Tue, 27 Feb 2024 15:05:01 +0000	[thread overview]
Message-ID: <877ciqvtgi.fsf@esperi.org.uk> (raw)
In-Reply-To: <87bk828z6q.fsf@gentoo.org> (Sam James's message of "Tue, 27 Feb 2024 01:37:33 +0000")

On 27 Feb 2024, Sam James said:

> Nicholas Vinson <nvinson234@gmail.com> writes:
>
>> The functions ctf_label_set(), ctf_label_get(), ctf_arc_open(), ctf_fdopen(),
>> ctf_open(), ctf_bfdopen(), and ctf_bfdopen_ctfsect() are not defined. Their
>> inclusion in libctf/libctf.ver causes clang/llvm LTO optimizatiosn to fail with
>> error messages similar to

This is definitely not right. They *are* defined, but only for some
libraries built from this version script. You can't just take them out.

>> Fixes Gentoo bug 914640 (https://bugs.gentoo.org/914640)
>>
>> Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
>> ---
>>  libctf/libctf.ver | 8 --------
>>  1 file changed, 8 deletions(-)
>
> [CCing a possible reviewer.]
>
>>
>> diff --git a/libctf/libctf.ver b/libctf/libctf.ver
>> index 0ff825d033b..08e1b27341f 100644
>> --- a/libctf/libctf.ver
>> +++ b/libctf/libctf.ver
>> @@ -80,9 +80,6 @@ LIBCTF_1.0 {
>>  	ctf_enum_name;
>>  	ctf_enum_value;
>>  
>> -	ctf_label_set;
>> -	ctf_label_get;
>> -
>>  	ctf_label_topmost;
>>  	ctf_label_info;
>
> Can you explain each of these? Were they ever in binutils/libctf
> (possible typos) or did they get removed?

The ctf_label things are historical artifacts from the Solaris days used
by their old stabs-based deduplicator. Some of the code remains, and I
have hopes of repurposing much of it and the unused CTF file format
section for a better way of encoding child dicts with conflicting types
in them in the future, but ctf_label_{set,get} appear to have been
nonexistent for as long as I've had anything to do with libctf. They
should be removed from ctf-api.h too.

>>  
>> @@ -139,7 +136,6 @@ LIBCTF_1.0 {
>>  
>>  	ctf_arc_write;
>>  	ctf_arc_write_fd;
>> -	ctf_arc_open;
>>  	ctf_arc_bufopen;
>>  	ctf_arc_close;
>>  	ctf_arc_open_by_name;
>> @@ -165,10 +161,6 @@ LIBCTF_1.0 {
>>  	ctf_link_shuffle_syms;
>>  	ctf_link_write;
>>  
>> -	ctf_fdopen;                             /* libctf only.  */
>> -	ctf_open;                               /* libctf only.  */
>> -	ctf_bfdopen;                            /* libctf only.  */
>> -	ctf_bfdopen_ctfsect;                    /* libctf only.  */
>>      local:
>>  	*;
>>  };

These are definitely used, and exist -- as the comments note, some of
them exist only in libctf.so, not in libctf-nobfd.so.

lld is not the first linker to complain about missing symbols: recent
Solaris linkers do as well, so we arranged to mark such symbols as
/* libctf only. */ so that they can be removed from the version script
used to link ctf-nobfd.so (see libctf/configure.ac for the code that
does that). But here too we have a bug: ctf_arc_open is in
ctf-open-bfd.c, thus is not found in libctf-nobfd.so: it should be at
the end of the version script like all other such symbols and marked as
/* libctf only. */ as well. 

-- 
NULL && (void)

  parent reply	other threads:[~2024-02-27 15:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28 19:10 Nicholas Vinson
     [not found] ` <87bk828z6q.fsf@gentoo.org>
2024-02-27 15:05   ` Nick Alcock [this message]
2024-02-28  0:32     ` Nicholas Vinson
2024-02-28 18:14       ` Nick Alcock
2024-03-01  1:49         ` Nicholas Vinson
2024-03-01 17:46           ` Nick Alcock
2024-03-02  3:36             ` 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=877ciqvtgi.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).