This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: News MIPS option -mno-shared
"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Thu, 9 Dec 2004, Ian Lance Taylor wrote:
>
> > The idea is that you can use -KPIC -mno-shared and get code which
> > still uses the usual Unix calling convention, but is slightly more
> > efficient at each function entry. Of course, the resulting code is
> > not position independent and can not be put into a shared library.
>
> The resulting naming of options is a bit unfortunate -- -KPIC suggests
> the result is PIC regardless of other options.
The option naming in general is somewhat confusing. -KPIC doesn't
really mean PIC in the sense that -fpic does to gcc. It means to use
the Unix calling conventions, which are designed to be PIC. -KPIC
affects how some pseudo-ops and instructions like jal are interpreted.
You can easily write non-PIC code while using -KPIC. A synonym for
-KPIC is -mcall_shared, which is perhaps a better name.
> > Hence the name -mno-shared. (Note that nothing will prevent you from
> > trying to put -mno-shared code into a shared library, but the
> > resulting shared library will not work correctly.)
>
> Shouldn't the relocations be forwarded to the .rel.dyn section upon
> static linking for resolution (or complaint) by ld.so? Like it happens
> for other platforms where you can build PDC shared libraries that still
> work. Not that such libraries are optimal, but still better than ones
> that silently break.
I don't think it will work, because the resulting relocation will be
against the _gp symbol, which is specific to the executable, not to
the shared link of the executable and the shared library. The dynamic
linker will probably use the wrong value of _gp when resolving this
relocation. I suppose it would be possible to make it work through
some further hackery, but I doubt anybody would really want to use it.
Ian