[llvm-dev] llvm bug 11944

[David Blaikie via llvm-dev]

[It might be helpful if you used a few more words & fully explained
what you're referring to - I'm having a hard time following your
emails in this abbreviated writing style]

You looked at an existing bug (do you have a link to it, or bug number
on the bugs.llvm.org database) related to the use of global
constructors in the LLVM codebase? Or in another codebase using LLVM?

You had similar issues on another codebase you worked on where you
weren't allowed to use any non-trivial global constructors?

& you're proposing creating a checker or other tool to help find these
cases? Or proposing using an existing tool for finding such things?

Clang does have a warning for this already, I believe:
-Wglobal-constructors. But, yes, the LLVM codebase isn't remotely
ready for that and it's not been a high enough priority for anyone to
really clean it up - mostly because the main use of global
constructors is in the LLVM command line argument handling code - so
it's a non-trivial design/redesign/refactoring effort to figure out
the right new design for that and make all the changes necessary to
migrate to such a design. (after that there'd probably be a bunch of
smaller more incremental changes to cleanup global constructors and
get the codebase to have no -Wglobal-constructors warnings, then we
could turn on the warning to ensure we didn't regress)

 - Dave

On Thu, Apr 22, 2021 at 4:50 PM pawel k. via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello,
> I took glimpse of PR llvm and or clang has ie lib cpp compound constructing global vars which makes objects get constructed in random order and with nonzero startup cpu/time overhead.
>
> In one of rather mighty embedded projects for 4g enodeb and later 5g base stations we had similar issue. It was forbidden to complex construct global vars.
>
> We could fancy clang syntax checker having option to early detect and track those so we could now how many are still left if any. I would disencourage running it on testsuite though as there were many false positives reported there.
>
> Happy if that helps any.
>
> Best regards,
> Pawel Kunio
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev