> On 10 Dec 2021, at 16:07, Rasmus Villemoes wrote:
>
>>
>> This is OK, can you please commit?
>
> Well, yes, but it depends contextually (but not functionally) on patch
> 2/4. Should I redo this one, or can I get you to take a look at 2/4 first?
>
> You've already ok'ed 1/4 and 4/4 (which
On 10/12/2021 15.20, Olivier Hainque wrote:
> Hi again Rasmus,
>
>> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>>
>> When the translation unit itself creates pointers to the ctors/dtors
>> in a specific section handled by the linker (whether .init_array or
>> .ctors.*), there's no reason
Hi again Rasmus,
> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>
> When the translation unit itself creates pointers to the ctors/dtors
> in a specific section handled by the linker (whether .init_array or
> .ctors.*), there's no reason for the functions to have external
> linkage. That
Hi Rasmus,
We had something close but slight different for
the support of shared libraries (for which I'm preparing
the patches). I think your version should work as well
but we have quite a few configurations and the devil is
in the details so I'm testing the effects in a few cases
before
When the translation unit itself creates pointers to the ctors/dtors
in a specific section handled by the linker (whether .init_array or
.ctors.*), there's no reason for the functions to have external
linkage. That ends up polluting the symbol table in the running
kernel.
This makes vxcrtstuff.c
