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

[Michael Matz]

Hi,

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.


Ciao,
Michael.