[patch][gold] Fix R_ARM_TLS_LE32 when there is no TLS segment
Wed May 26 22:25:00 GMT 2010
> I'm having trouble understanding this patch. If you have SHF_TLS
> sections but you don't have a PT_TLS segment, then as far as I can see
> your program isn't going to work. While I can certainly see the
> advantage of producing a better error message, I don't see why the
> linker should be concerned about just which value it generates. The
> program will fail at runtime anyhow.
A regular program will. This is a reduction from an issue in native
client. In native client we use the linker script to provided three
__tls_template_start, __tls_template_tdata_end and
__tls_template_end. With these symbols the runtime can do the job that
is normally done by ld.so.
I am not sure I understand the reasoning for doing it this way, but
apparently it is because the ELF header doesn't pass the validator and
therefore is not loaded. It should be possible to get the loader to
find the PT_TLS segment and pass that information down, but that would
complicate a part of the trusted code. For more information see
> That said, a few mechanical comments on the last version of the patch:
>> @@ -8679,6 +8679,23 @@ Target_arm<big_endian>::Relocate::relocate(
>> return true;
>> +template<bool big_endian>
>> +Output_section *
>> +relocated_section(const Relocate_info<32, big_endian>* relinfo,
>> + const elfcpp::Rel<32, big_endian>& rel,
>> + const Sized_symbol<32>* gsym)
> This is going to make a global function relocated_section, not a good
> idea. It should be a static member of Target_arm.
I made it static, is that OK?
I did all other changes as requested.
Rafael Ávila de Espíndola
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5800 bytes
Desc: not available
More information about the Binutils