On 27/09/14 08:56, Andrew Haley wrote:
> I may be guilty of missing a crucial point here, but: why do we care
> about having a small limit of static TLS variables?
>
> We surely could allocate, say, a megabyte of static TLS for each
> thread. We already allocate 64M for the thread-local malloc ar
I may be guilty of missing a crucial point here, but: why do we care
about having a small limit of static TLS variables?
We surely could allocate, say, a megabyte of static TLS for each
thread. We already allocate 64M for the thread-local malloc arena,
after all. It doesn't cost anything beyond
> On Fri, Sep 26, 2014 at 04:17:14AM +0200, Jan Hubicka wrote:
> > I was building libreoffice with profile feedback and I run into a message
> >
> > cannot load any more object with static TLS
> >
> > that took me a while to track as I did not see where static TLS is comming
> > out.
> > Ian poi
On Fri, Sep 26, 2014 at 04:17:14AM +0200, Jan Hubicka wrote:
> I was building libreoffice with profile feedback and I run into a message
>
> cannot load any more object with static TLS
>
> that took me a while to track as I did not see where static TLS is comming
> out.
> Ian pointed out to me t
On 2014.09.26 at 04:50 +0200, Jan Hubicka wrote:
> What is the earlierst binutils release fixing the bug? I will add it into
> changes.html for 5.0.
binutils-2.24
--
Markus
> > Thank you! Now when I have your attention, perhaps we could discuss the
> > original
> > motivation of the change that exposed this bug.
> > I was building libreoffice with profile feedback and I run into a message
> >
> > cannot load any more object with static TLS
> >
> > that took me a whil
> Thank you! Now when I have your attention, perhaps we could discuss the
> original
> motivation of the change that exposed this bug.
> I was building libreoffice with profile feedback and I run into a message
>
> cannot load any more object with static TLS
>
> that took me a while to track as I
> The plugin API doesn't have a way to mark a symbol as TLS, but it
> doesn't really matter since the linker simply overrides the
> placeholder from the claimed file with the symbol provided in the
> replacement. Unfortunately, I excluded common symbols from this logic
> in gold, so the symbol isn'
The plugin API doesn't have a way to mark a symbol as TLS, but it
doesn't really matter since the linker simply overrides the
placeholder from the claimed file with the symbol provided in the
replacement. Unfortunately, I excluded common symbols from this logic
in gold, so the symbol isn't getting
> On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu wrote:
> > On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor wrote:
> >> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka wrote:
> >>>
> >>>b: 00 00
> >>> 9: R_X86_64_TPOFF32
> >>> __gcov_indirect_call_counters_ltopriv
> >
On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu wrote:
> On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor wrote:
>> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka wrote:
>>>
>>>b: 00 00
>>> 9: R_X86_64_TPOFF32
>>> __gcov_indirect_call_counters_ltopriv
>>
>> Look at the
> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka wrote:
> >
> >b: 00 00
> > 9: R_X86_64_TPOFF32
> > __gcov_indirect_call_counters_ltopriv
>
> Look at the .o file where __gcov_indirect_call_counters_ltopriv is
> defined. That .o file must have the symbol marked as
On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor wrote:
> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka wrote:
>>
>>b: 00 00
>> 9: R_X86_64_TPOFF32
>> __gcov_indirect_call_counters_ltopriv
>
> Look at the .o file where __gcov_indirect_call_counters_ltopriv is
>
On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka wrote:
>
>b: 00 00
> 9: R_X86_64_TPOFF32
> __gcov_indirect_call_counters_ltopriv
Look at the .o file where __gcov_indirect_call_counters_ltopriv is
defined. That .o file must have the symbol marked as STT_TLS and it
>
> I'm not sure because my line numbers don't match. If it is this
> assert:
>
> case elfcpp::R_X86_64_TPOFF32: // Local-exec
> if (tls_segment == NULL)
> {
> gold_assert(parameters->errors()->error_count() > 0
> || issue_undefined_symbol_err
On Wed, Sep 24, 2014 at 11:18 AM, Jan Hubicka wrote:
>> On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote:
>> > Hi,
>> > libreoffice fails to build with TLS because of "Cannot load any more object
>> > with static TLS". Iant pointed out to me the difference that the initial
>> > exec
>> > TLS model
On 2014.09.24 at 20:18 +0200, Jan Hubicka wrote:
> > On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote:
> > > Hi,
> > > libreoffice fails to build with TLS because of "Cannot load any more
> > > object
> > > with static TLS". Iant pointed out to me the difference that the initial
> > > exec
> > > T
> On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote:
> > Hi,
> > libreoffice fails to build with TLS because of "Cannot load any more object
> > with static TLS". Iant pointed out to me the difference that the initial
> > exec
> > TLS model is also used by static TLS variables.
> >
> > This patch p
On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote:
> Hi,
> libreoffice fails to build with TLS because of "Cannot load any more object
> with static TLS". Iant pointed out to me the difference that the initial exec
> TLS model is also used by static TLS variables.
>
> This patch prevents turning TLS
Hi,
libreoffice fails to build with TLS because of "Cannot load any more object
with static TLS". Iant pointed out to me the difference that the initial exec
TLS model is also used by static TLS variables.
This patch prevents turning TLS variables into static that lets me to finish
libreoffice bui
20 matches
Mail list logo
