This is the mail archive of the
mailing list for the binutils project.
Re: [SH] TLS IE -> LE optimization issue
- From: David Miller <davem at davemloft dot net>
- To: thomas at codesourcery dot com
- Cc: binutils at sourceware dot org, aoliva at redhat dot com, kkojima at rr dot iij4u dot or dot jp
- Date: Fri, 13 Apr 2012 11:53:16 -0400 (EDT)
- Subject: Re: [SH] TLS IE -> LE optimization issue
- References: <firstname.lastname@example.org>
From: Thomas Schwinge <email@example.com>
Date: Fri, 13 Apr 2012 17:48:06 +0200
> (This is also where the (dummy) SO comes into play: otherwise »dyn ==
> NULL«.) Back in sh_elf_size_dynamic_sections, »srelgot->size != 0«
> (»sizeof (Elf32_External_Rela) == 12«), thus memory for this section will
> be allocated (using bfd_zalloc). Later on, in sh_elf_relocate_section,
> the linker recognizes that TLS IE can here be optimized into TLS LE, and
> does so; the relocation slot is now not needed anymore (so
> srelgot->reloc_count is not incremented), but it is not reclaimed/the
> size reservation remains (and due to using zalloc, it's a R_SH_NONE), and
> thus the assertion is triggered.
> Expectedly, weakening the assertion into using <= instead of == makes the
> problem go away, but the empty slot in .rela.dyn remains (12 bytes
> Or, instead, should the srelgot->size reservations be un-done as the TLS
> optimizations are done (there may be other such cases, I didn't check)?
> Can this actually be done at this stage?
> Or, should there be another cleanup pass after the TLS optimizations have
> been done? Or, should one of the existing passes in fact be catching
> this case, too?
Sparc, which makes similar transformations, lacks the assertion you
In fact SH is one of the few backends I see making this size check.