Re: [Gcl-devel] hppa porterbox access

[Camm Maguire]

Greetings!

John David Anglin <address@hidden> writes:

> Hi Camm,
>
> On 3/24/2014 12:56 PM, Camm Maguire wrote:
>> Greetings!  One more gcl linker anomaly on hppa.  ld writes internal
>> hidden local function symbols, e.g. __moddi3 for modular arithmetic,
>> into the executable and silently rewrites % to call it, even though it
>> is not visible to the link unit using ordinary semantics, i.e. __moddi3
>> is neither a global nor weak symbol.  The st_info field in the elf sym
>> data structure has binding type STB_LOCAL and symbol type STT_FUNC.
>> There are of course many many other such local functions which gcl would
>> like to know that subsequent compiled code could never reference, and
>> which therefore it will eliminate from its internal symbol table.  So I
>> need some method of making only these specially inserted hppa symbols
>> global or equivalent.  A dirty but working hack is
>>
>> #define FIX_LOCAL_SYM(st1,sym) {if (ELF_ST_BIND(sym->st_info)==STB_LOCAL && 
>> ELF_ST_TYPE(sym->st_info)==STT_FUNC && *(st1+sym->st_name)=='_') 
>> sym->st_info|=1<<4;}
>>
>> Can you provide any insight here on what is the 'right' thing to do?

>
> I don't fully understand the situation.  Any module linked against
> libgcc and milli.a will
> never need to call __moddi3, etc.  The situation at that stage seems
> equivalent to that
> for a function that was originally local.  Is gcl trying to load
> modules that haven't been
> linked against libgcc and milli.a, and do the dynamic linking itself?

OK, the gcl binary is produced with gcc and ld in the normal fashion,
with internal __moddi3 calls generated correctly as you state.  gcl has
a special feature of compiling and linking new code into this binary
image at runtime, and being able to save the new image to disk in elf
format for subsequent execution.  This 'native object code loading and
relocation' does not use ld, and is implemented by gcl itself.  It works
on all official Debian architectures and some legacy ones.

So at runtime, gcl will take some lisp, translate to C, run gcc -c in a
subprocess, map and parse the .o file produced, relocate it into freshly
sbrked .data memory, mprotect, and execute, later saving to disk via
unexec (as in emacs).  So I need to ape ld's routine of encountering a
__moddi3 reference, and relocating the call to the __moddi3 previously
compiled and linked into the running gcl (e.g. via ld at gcl build
time).  Like ld, I want to treat __moddi3 specially, performing the link
without error, whereas other potential references to non-global non-weak
symbols should generate a linker error.  In short, I'm looking for some
algorithm to identify all such __moddi3 like symbols in order to
separate their processing from any generic error-producing symbol.

In my dream world, gcc would write a type flag to st_info or st_other
making this distinction for me.  mips does something similar with
'hidden symbols', using some 'visibility' flag logic in st_other letting
the linker know it should find the appropriate address elsewhere.  gcl
handles these correctly at present.

Thanks so much for your help.  Please ask questions if this is still not
clear. 

>
> The '_' check seems like a big hack.

Indeed.  Just done on my machine to verify the linker at the moment.

>
> It is possible to affect whether linkage is against archive or shared
> libgcc.
>

Maybe this is the route.  It would seem both a gcc and ld (via -Wl,)
flag would be needed to make sure the symbol reference in the .o file
was of bind type STB_GLOBAL.  This is probably a little slower though.
If this is best, please point me to the relevant switches if you have a
moment.

Thanks again!

> Dave

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