[Top][All Lists]

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

[Gcl-devel] Re: mips64 assembler

From: Camm Maguire
Subject: [Gcl-devel] Re: mips64 assembler
Date: Thu, 30 Sep 2010 10:06:37 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)


David Daney <address@hidden> writes:

>> On other machines with a .plt (e.g. alpha), I don't leave the gp at
>> its 'canonical' value, but rather set it to a mini-table I craft at
>> the end of the code to be loaded.  I then populate this .got
>> accordingly.  The _setjmp address I use is the address of the .plt
>> entry.  This will always call the .plt entry and never reset the new
>> .got slot, as the .plt is designed to set the .got slot of the base
>> executable.  So the call is somewhat inefficient, but it works and is
>> stable.   On mips, if I move the gp pointer to my mini-table, it will
>> no longer be correct in the stub where it is used to lookup the lazy
>> relocator of libdl in the .got of the base executable.
> The entry point of the lazy resolver is always at a fixed location in
> the GOT.  So if you are creating a GOT, just make sure you reserve the
> slots that are used by ld.so.
> The stubs are a little unique in this manner.  They rely on a valid gp
> at entry.  All other functions calculate their own gp and don't care
> about the value of gp passed on entry.

Thank you again so much for this discussion.  One last item -- alpha
has a similar reloc structure to mips.  Here external symbols such as
__divq do not get a plt entry, even if their addresses are taken as
function pointers explicitly in the code.  Rather they are put into a
separate table with a R_ALPHA_GLOB_DAT relocation record.  Is there
any way I can force a genuine plt entry for these?  And what is the
criterion used for treating such symbols differently?

Take care,
Camm Maguire                                        address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

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