On Thu, Apr 22, 2021 at 7:47 PM pawel k. <pawel.kunio at gmail.com>
wrote:>
> Hello,
> Sorry about my bad english and wrecked communications line. I meant 11944
bug from llvm database. As on our system, we had similar issue in sense on
embedded project around lte and 5g base stations. Archs finally decided global
compound constructors are forbidden due to startup overhead and call order
unpredictability.
>
> Thank You for mentioning warning enabling flag. That should help me
pinpoint all interesting uses of this construct.
Sure thing - oh, the other thing you might find interesting, regarding
the issues with global constructor ordering problems - there's a
dynamic tool to help find those:
https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco
> I will try to lookup how these global constructors are done in llvmlib.
What i saw as general guideline along which commandline opts component is built
i generally like. I dont see yet fully where is issue in moving it to runtime.
Id think we could try to use some pattern like commandline opts tables from gcc
but nit sure yet whether keep much in globals or store within specific
apps/tools classes.
>
> In one of first phases id think of checking buildflags of clang what
targets etc are enabled and register all supported commands and maybe prescan
command line for further flags which enable or disable other flags.
>
> I will try to build llvm lib with this warning enabled to see all opts uses
and learn the api etc. I need to understand furst completely based on what logic
macros and flags which flags blocks should be registered and later kept or
disabled if we need to scan commandline in multiple passes etc.
I will say I wouldn't readily suggest this as the /best/ place to
start in LLVM - if you're interested in getting into the project
generally, without any particular preference for which part - given
this has been thought about a fair bit by folks throughout the
project's life, the amount of design work/time involved by core
developers will probably be non-trivial to figure out the right path
before the mechanical work can begin. Fair warning.
Usually I suggest starting with clang warnings (or
clang-format/clang-tidy these days) bugs, since they can be fairly
narrow/sometimes relatively isolated to fix. Source location bugs or
fixits (warnings that point to the wrong part of the code, or errors
that don't offer a fixit hint when they could) can be interesting
learning experiences about the Clang Abstract Syntax Tree/source
location information.
But if you're more interested in LLVM proper - probably middle-end
misoptimizations (probably easier to fix bugs/miscompiles than fixing
missed optimizations - the latter are probably more likely to be
deeply involved work/changes to make an optimization more powerful for
some reason).
> Ill try to learn all i can first from code and gathered warnings and if
questions arise ill ring back with them and if not ill try to propose some
solution after fully testing it on current testsuite and all targets etc.
Yep, always happy to answer questions/provide pointers.
- Dave
>
> Best regards,
> Pawel Kunio
>
>
> pt., 23.04.2021, 02:30 użytkownik David Blaikie <dblaikie at
gmail.com> napisał:
>>
>> [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