Greetings! David Daney <dda...@caviumnetworks.com> 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 c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
