tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated execut


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
Date: Fri, 22 May 2015 08:36:09 +0800
User-agent: K-9 Mail for Android

On May 21, 2015 9:58:07 AM GMT+08:00, Michael Matz <address@hidden> wrote:
> Hi,
> 

Hi Michael,

I knew you'd know :-) 

> 
> No, the missing of .got.plt is a red herring (it's used to implement a
> 
> security feature to isolate .got slots that can be written to also
> after 
> program relocation from those can can't).

I thought difference of security but stopped at the fact that they both need to 
be written and just skipped the fact that of course privileges (write access) 
can be dropped (mremap).

> 
> The real problem is, that the dynamic linker only resolves relocations
> 
> lazily that are consecutive and properly announced in the ELF dynamic 
> section.  Normal relocations are found by the DT_RELA/DT_RELASZ 
> (DT_RELAENT) entries, they describe where in the ELF file relocations
> are 
> found (note that sections are completely irrelevant for the loader). 
> Then there's also an DT_JMPREL/DT_PLTRELSZ (DT_PLTREL) pair that
> describes 
> where the _lazy_ relocations are to be found.  This was for a RELA
> arch, a 
> REL one is equivalent.

Of course! Thank you! I did look at missing DT flag but not at the presence if 
2 instead of 1. Shame on me, 2 errors in one debugging session.

> 
> So, if the latter is missing (and hence all relocs are bounded by the 
> first pair) then all relocs are done eagerly.

Right.

> 
> So, tcc needs to emit relocations a bit different: either sorting by
> type, 
> then describing the JUMP_SLOT relocs with the DT_JMPREL pair (and
> exclude 
> them from the DT_RELA pair), or keeping JUMP_SLOT and other relocs 
> separate from the start, but still using the two pairs to describe
> lazy 
> and non-lazy relocs.

I'll do the latter. It's cleaner and not more complicated.

Thanks again and thanks also to Sergey for helping me out ;-) 

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]