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

[Wael Yehia via 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 04:03PM
Cc: "Fangrui Song" <maskray at google.com>, "LLVM-DEV LIST" <llvm-dev at lists.llvm.org>
Subject: [EXTERNAL] Re: [llvm-dev] [libLTO] accessing llvm.global_ctors


>> On Jul 26, 2021, at 10:59 AM, Wael Yehia <wyehia at ca.ibm.com> wrote:
>> 
>> 
>> 
>> 
>> -----"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. 
>
>The reason why I don't want to do that is because they are not real symbols and linker do not know how to resolve them. You could stamp a different attribute on them but the old linker will not be able to understand them.

Just to be clear, i'm not proposing that these two symbols start being accessible through the `lto_module_get_[num_symbols|symbol_name|symbol_attribute]` functions (which would make them visible to a linker).
I'm proposing something like:

lto_bool_t lto_module_has_ctor_dtor(lto_module_t mod) {
  return unwrap(mod)->hasCtorDtor();
}

bool LTOModule::hasCtorDtor() {
   // either (1) traverse `ModuleSymbolTable SymTab` or 
   // (2) compute and cache the answer when LTOModule::parseSymbols runs
}