ld.so mechanism

ld.so mechanism

[Jeson Martajaya]

Hello,

I have a Thesis that have a topic "Remote Dynamic Linking". My plan is
trying to expand the role of Linux linker/loader, ld.so, from
linking/loading a particular program to a shared library that is stored in
remote computer.

I have several preliminary questions:

1. Suppose a C function that have signature "int foo(int)" that is stored in
foolib.so . Suppose prog.c has a line "extern int foo(int)". Do you know
where does this foo signature is stored, so that ld can automatically link
prog.c to this function?

2. Which file in the gcc-3.2.2 sourcecode should I begin to look at? I'm
using Redhat 8.0 that is using the latest gcc (3.2.2 20030923)

Thank you so much for your help,

Jeson Martajaya
University of Texas at Austin
Computer Science Department

Re: ld.so mechanism

[Andrea 'fwyzard' Bocci]

>I have several preliminary questions:

I don'y know anything about this, but ld.so, but I don't think thgis is the 
right mailing list to ask:
.) ld.so is the dynamic linker, so you might try on the binutils mailing list
.) on my RedHat 8, it comes packaged with glibc, so you might ask the glibc 
people
.) man 8 ld.so mentions a couple things about where ld.so gets its info, 
but I'm not familiar with it. I guess you already looked there, though ;-)

>1. Suppose a C function that have signature "int foo(int)" that is stored in
>foolib.so . Suppose prog.c has a line "extern int foo(int)". Do you know
>where does this foo signature is stored, so that ld can automatically link
>prog.c to this function?
>
>2. Which file in the gcc-3.2.2 sourcecode should I begin to look at? I'm
>using Redhat 8.0 that is using the latest gcc (3.2.2 20030923)


>I have a Thesis that have a topic "Remote Dynamic Linking". My plan is
>trying to expand the role of Linux linker/loader, ld.so, from
>linking/loading a particular program to a shared library that is stored in
>remote computer.

Can't you simply put all the .so libaries on a  NFS share, export it, and 
configure ld.so to loock there ?

.fwyzard.

Re: ld.so mechanism

[Mike Stump]

On Monday, March 24, 2003, at 11:13 PM, Jeson Martajaya wrote:
> I have a Thesis that have a topic "Remote Dynamic Linking". My plan is
> trying to expand the role of Linux linker/loader, ld.so, from
> linking/loading a particular program to a shared library that is 
> stored in
> remote computer.
>
> I have several preliminary questions:
>
> 1. Suppose a C function that have signature "int foo(int)" that is 
> stored in
> foolib.so . Suppose prog.c has a line "extern int foo(int)". Do you 
> know
> where does this foo signature is stored, so that ld can automatically 
> link
> prog.c to this function?

Since you willed the information into existence with your supposition, 
you will have to tell us where it is, as you're calling the shots.  If 
you want to ask us, where should you put it, that is a different 
question.  The answer to that question would be inappropriate for this 
list, rather, binutils would be the appropriate place for that 
discussion.  My guess is they would recommend either in the symbol 
table someplace, or in the debugging information.  For more detail, 
you'd have to ask them and/or consult the documentation on the symbol 
table and/or debugging information.

Currently, the only thing that is always stored is the string "foo".  
More things might always be stored, depending upon the OMF and the OS.  
To find the string foo, you will want to check out nm, readelf or 
objdump in binutils.

> 2. Which file in the gcc-3.2.2 sourcecode should I begin to look at?

dbxout.c/dwarf2out.c contain the debugging information code, and the 
port files can contain additional code to generate additional 
information.