llvm dev - Jul 2021 - [libLTO] accessing llvm.global_ctors

>>Hi,
>>Our linker uses the libLTO interface. Given an lto_module_t, we are
trying to
>>check if it contains the @llvm.global_ctors or the @llvm.global_dtors
global
>>variables. We need to know this information in order to decide whether
to
>>include a bitcode archive member in the LTO step or not.
>
>This is strange. Constructors should be orthogonal to archive member
extraction.
>If an archive member is unused, it is not extracted and its constructors
>are suppressed.
Certain linker flag forces it to include all archive members that have a
constructor or destructor. I agree it's strange.

I am fine with adding a new C API to read the constructor and destructor if
needed. I don't think it makes sense to encode llvm.global_ctors and
llvm.global_dtors into the symbol table since they are not symbols. It also
sounds like that you just need to know if the object file has constructor or
not, but don't really care anything more than that? Can you read the section
name from the IRSymtab to figure out if that is a constructor/destructor or not?
> On Jul 25, 2021, at 4:39 PM, Wael Yehia via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> 
>>> Hi,
>>> Our linker uses the libLTO interface. Given an lto_module_t, we are
trying to
>>> check if it contains the @llvm.global_ctors or the
@llvm.global_dtors global
>>> variables. We need to know this information in order to decide
whether to
>>> include a bitcode archive member in the LTO step or not.
>> 
>> This is strange. Constructors should be orthogonal to archive member
extraction.
>> If an archive member is unused, it is not extracted and its
constructors
>> are suppressed.
> 
> Certain linker flag forces it to include all archive members that have a
constructor or destructor. I agree it's strange.
Is it possible to disclose what linker and what platform that is? You don't
have to but it would be easier to maintain if you can document this behavior
that is unique to the platform you are looking at.

Thanks

Steven
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-----"Steven Wu" <stevenwu at apple.com> wrote: -----
To: "Wael Yehia" <wyehia at ca.ibm.com>
From: "Steven Wu" <stevenwu at apple.com>
Date: 07/26/2021 12:22PM
Cc: "Fangrui Song" <maskray at google.com>, llvm-dev at
lists.llvm.org
Subject: [EXTERNAL] Re: [llvm-dev] [libLTO] accessing llvm.global_ctors
> It also sounds like that you just need to know if the object file has
constructor or not, but don't really care anything more than that?
yes

> Can you read the section name from the IRSymtab to figure out if that is a
constructor/destructor or not?
Is this a suggestion of how to implement the query I'm after?
My initial thought was to simply check for the presence of the symbols
`llvm.global_ctors` and `llvm.global_dtors` in the ModuleSymbolTable in the
LTOModule.

 
>> Certain linker flag forces it to include all archive members that have
a constructor or destructor. I agree it's strange.
>
> Is it possible to disclose what linker and what platform that is? You
don't have to but it would be easier to maintain if you can document this
behavior that is unique to the platform you are looking at.
The linker is the system linker on AIX, and the option is -bcdtors:all
(documented here: https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command)