Re: [PING^2][PATCH] libgcc, emutls: Allow building weak definitions of the emutls functions.

Iain Sandoe writes: > Hi, > > So let’s ignore the questions for now - OK for the non-Darwin parts of the > patch ? Looks OK to me. Thanks, Richard > >> On 24 Sep 2021, at 17:57, Iain Sandoe wrote: >> > >> as noted below the non-Darwin parts of this are trivial (and a no-OP). >> I’d like to ap

Re: [PING^2][PATCH] libgcc, emutls: Allow building weak definitions of the emutls functions.

Hi, So let’s ignore the questions for now - OK for the non-Darwin parts of the patch ? > On 24 Sep 2021, at 17:57, Iain Sandoe wrote: > > as noted below the non-Darwin parts of this are trivial (and a no-OP). > I’d like to apply this to start work towards solving Darwin’s libgcc issues, >> On

[PING}[PATCH] libgcc, emutls: Allow building weak definitions of the emutls functions.

Hi, as noted below the non-Darwin parts of this are trivial (and a no-OP). I’d like to apply this to start work towards solving Darwin’s libgcc issues, OTOH, the two raised questions remain… thanks Iain > On 20 Sep 2021, at 09:25, Iain Sandoe wrote: > > Hi, > > The non-Darwin part of this pat

[PATCH] libgcc, emutls: Allow building weak definitions of the emutls functions.

Hi, The non-Darwin part of this patch is trivial but raises a couple of questions A/ We define builtins to support emulated TLS. These are defined with void * pointers The implementation (in libgcc) uses the correct type (struct __emutls_object *) in both a forward declaration of the functions an