Re: News MIPS option -mno-shared

[Ian Lance Taylor <ian@wasabisystems.com>]

"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