Re: [Gcl-devel] Re: function addresses and ld.so

[Camm Maguire]

Greetings, and thanks for your very helpful reply!

David Mosberger <address@hidden> writes:

> >>>>> On Tue, 12 Aug 2003 18:24:47 -0400, Camm Maguire <address@hidden> said:
> 
>   Camm> GCL stores addresses of its functions in data structures
>   Camm> allocated in the normal way in its .data section.  It then
>   Camm> runs an unexec routine which saves the memory image including
>   Camm> these addresses to a file.
> 
> Isn't this a dangerous thing to do even on non-function-descriptor
> architectures?  If I understand you right, GCL depends on the loader
> mapping the shared objects on subsequent executions at the exact same
> location as during the original execution.  Wouldn't, e.g.,
> LD_PRELOADing something break this assumption?
> 

The code does not depend on shared library mappings being identical,
but only the .text, .data, and perhaps .bss mappings of the executable
itself being identical across multiple executions.  I don't know if
this assumption is well founded, or what circumstances can lead to its
violation, but LD_PRELOADing is just fine:

=============================================================================
localhost:~$ maxima &
localhost:~$ cat /proc/$(pidof maxima)/maps
08048000-081c5000 r-xp 00000000 09:01 1459       
/usr/lib/maxima/5.9.0/binary-gcl/maxima
081c5000-08bba000 rw-p 0017c000 09:01 1459       
/usr/lib/maxima/5.9.0/binary-gcl/maxima
08bba000-0958b000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 09:01 48305      /lib/ld-2.2.5.so
40013000-40014000 rw-p 00013000 09:01 48305      /lib/ld-2.2.5.so
4001f000-4003f000 r-xp 00000000 09:01 49177      /lib/libm-2.2.5.so
4003f000-40040000 rw-p 0001f000 09:01 49177      /lib/libm-2.2.5.so
40040000-40067000 r-xp 00000000 09:01 128477     /usr/lib/libgmp.so.3.2.1
40067000-40068000 rw-p 00026000 09:01 128477     /usr/lib/libgmp.so.3.2.1
40068000-40069000 rw-p 00000000 00:00 0
40069000-40089000 r-xp 00000000 09:01 48216      /lib/libreadline.so.4.2
40089000-4008e000 rw-p 0001f000 09:01 48216      /lib/libreadline.so.4.2
4008e000-4008f000 rw-p 00000000 00:00 0
4008f000-400c4000 r-xp 00000000 09:01 49892      /lib/libncurses.so.5.2
400c4000-400cd000 rw-p 00034000 09:01 49892      /lib/libncurses.so.5.2
400cd000-401e0000 r-xp 00000000 09:01 48950      /lib/libc-2.2.5.so
401e0000-401e6000 rw-p 00113000 09:01 48950      /lib/libc-2.2.5.so
401e6000-401ea000 rw-p 00000000 00:00 0
bfff2000-c0000000 rwxp ffff3000 00:00 0
=============================================================================
localhost:~$ LD_PRELOAD=/usr/lib/libblas.so.2.0 maxima
localhost:~$ cat /proc/$(pidof maxima)/maps
08048000-081c5000 r-xp 00000000 09:01 1459       
/usr/lib/maxima/5.9.0/binary-gcl/maxima
081c5000-08bba000 rw-p 0017c000 09:01 1459       
/usr/lib/maxima/5.9.0/binary-gcl/maxima
08bba000-0958b000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 09:01 48305      /lib/ld-2.2.5.so
40013000-40014000 rw-p 00013000 09:01 48305      /lib/ld-2.2.5.so
40014000-40075000 r-xp 00000000 09:01 129775     /usr/lib/libblas.so.2.0
40075000-40076000 rw-p 00060000 09:01 129775     /usr/lib/libblas.so.2.0
40081000-400a1000 r-xp 00000000 09:01 49177      /lib/libm-2.2.5.so
400a1000-400a2000 rw-p 0001f000 09:01 49177      /lib/libm-2.2.5.so
400a2000-400a3000 rw-p 00000000 00:00 0
400a3000-400ca000 r-xp 00000000 09:01 128477     /usr/lib/libgmp.so.3.2.1
400ca000-400cb000 rw-p 00026000 09:01 128477     /usr/lib/libgmp.so.3.2.1
400cb000-400eb000 r-xp 00000000 09:01 48216      /lib/libreadline.so.4.2
400eb000-400f0000 rw-p 0001f000 09:01 48216      /lib/libreadline.so.4.2
400f0000-400f1000 rw-p 00000000 00:00 0
400f1000-40126000 r-xp 00000000 09:01 49892      /lib/libncurses.so.5.2
40126000-4012f000 rw-p 00034000 09:01 49892      /lib/libncurses.so.5.2
4012f000-40242000 r-xp 00000000 09:01 48950      /lib/libc-2.2.5.so
40242000-40248000 rw-p 00113000 09:01 48950      /lib/libc-2.2.5.so
40248000-4024c000 rw-p 00000000 00:00 0
bfff2000-c0000000 rwxp ffff3000 00:00 0
=============================================================================

All function addresses of this sort are in the first three maps.

What circumstances if any could lead to these three maps appearing at
different addresses?

I'm not vouching for the design, and think it needs some fixing, but
problems with it in practice are rare.  GCL has been shipping lisp
images in this fashion for many years.  As we increase the number of
shared libs, and expand to function descriptor platforms, we may be
exposing weaknesses more frequently of late, however.

I have a few ideas about how to robustify this forthcoming in a
separate email.  Would greatly appreciate your comments.

Take care,


>       --david
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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