Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b

[Michael Matz]

Hi,

On Tue, 9 Sep 2014, Thomas Preud'homme wrote:

> 1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT 
> relocations but the computation you added ignore the possible addend at 
> *ptr by doing a simple assignment. Is that normal? Did I miss something?

This is per the ABI.  The addend for both relocations (when using REL 
form) is (and must be) always zero.  I didn't bother checking for this, 
but rather just ignored anything that was in there.

> 2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or 
> R_ARM_JUMP24 you add the offset of the PLT entry to the place being 
> relocated. 
> I'm not sure I got it right but it seems to me that the relocation will be 
> processed again in relocate_section and seems the symbol referenced is still 
> the target function (and not the PLT entry created) as the index in the 
> r_info 
> field of the relocation has remained unchanged. Also this put some relocation 
> computation in build_got_entries. Why not change the initial relocation to 
> make it resolve to the PLT entry.

It might be that I got some of the logic wrong, though I obviously did 
check tcc on arm with itself (and IIRC gawk).  I'll need to reproduce the 
problem somewhen.  Are you positive that it was my commit that broke it?  
Hmm, or it might be that I also hit an error but somehow convinced myself 
that it was a pre-existing but possibly hidden problem.  Man, it's long 
ago :)

> 3) I don't see any test for the type of output when deciding what type of 
> relocation to add. So even when the output is in memory reloc_type will be 
> JUMP_SLOT which will lead to a PLT entry being created. This seems to 
> contradict the comment near the end of put_got_entry. The comment seems wrong 
> as I don't see how a branch could be relocated without a PLT entry.

I think what I wanted to convey in the comment is the following situation: 
normally with memory output (or static linking) no symbolic relocations 
whatsoever are required in the executable, because, well, everything is 
relocated from the beginning.  But the means by which that is ensured is 
itself (at least in TCCs link editor) by creating (and later processing) 
relocations.  Where it matters are indirect calls:

  extern void f(void);
  g() { void (*ptr)(void) = f; ptr(); }

Here there will be a GOT slot allocated for 'f'.  The initialization of 
'ptr' will load from that GOT slot.  So even though direct calls to 'f' 
can (and will be, when 'f' is defined) fully resolved without a PLT slot, 
this indirect access needs a GOT slot, and because of that also needs to 
initialize that slot with f's address, which is done by an relocation 
(which are processed for static and memory output right at the end of most 
processing).

> 4) the jump table that was removed in subsequent patch was only available 
> when 
> outputing to memory. But now a PLT and GOT entry is created no matter what 
> type of output (see 3) above).

Yes, PLT and GOT together (when unconditionally created) take over the 
role of the old jump table.

Now obviously I bungled something regarding all that on ARM and will have 
to look at the details.  Let me first try to reproduce and I'll come back.


Ciao,
Michael.