This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: the problem : assign the section's order in shared library based on mips platform


eagle_zhou@ali.com.tw writes:

> Yes, I am writing own dynamic loader/linker. And use our own operation
> system.
> 
> I have parsed all relocation info and generate my own data struct which
> will be
> resolved by my own dynamic loader/linker.
> 
> So i do not need it's other info(string,symbol,and so on) again.
> I only use it's text and data section.
> 
> my aim is putting text and data section into continuous space and take out
> them from .so file.
> but now, i meet those problem i mentioned.

If I were you I would rewrite the calling convention, including the
GOT and the PLT, into something appropriate for your system.  If you
don't want to do that, then you will need to get a clear understanding
of the current system.

If I understood your question correctly, you are wondering why the
stub code starts with the instruction
    lw   t9,-32752(gp)
In the current ELF support, MIPS stub code always starts with that
instruction.  The dynamic linker is responsible for filling that word
with the address of the runtime resolution routine.  The resolution
routine will then fill in the GOT entry for the initial function (in
your example, 140(gp)) so that future calls will bypass the stub
entirely.

One step you need to take if you want to go this path is to set _gp in
your linker script.  The linker will use that in calculating GP
relocations (at least, that is how it used to work; I don't know
whether there is a more intelligent way to set the GP value these
days).

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]