[Top][All Lists]

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

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

From: Michael Matz
Subject: Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
Date: Thu, 21 May 2015 03:58:07 +0200 (CEST)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)


On Thu, 21 May 2015, Thomas Preud'homme wrote:

On May 18, 2015 11:17:35 PM GMT+08:00, Sergey Korshunoff <address@hidden> wrote:
tries comparing the output of readelf -a for an hello world program
but there are too many
differences and I didn't spot anything obvious

there is no .got.plt section in the tcc generated exe. gcc don't
generate this section if bind_now. no (FLAGS attribute too.

Doh, indeed. How could I miss that? Actually I know, the diff was basically all deletions followed by all additions so I focused on common sections.

Anyway both sections (.got and .got.plt) have same access rights (WA) and the names shouldn't matter so does glibc changes it's behaviour if there is more than one section with (dynamic) relocations? Or does it check if a section is full of JUMP_SLOT only?

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).

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.

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

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 enable lazy relocation as part of the refactoring I'm doing as it's easier but will try to do an intermediary push as soon as I do it rather than wait to complete all the refactoring.


reply via email to

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