This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

ld, DSO's, R_386_RELOC


Hi,

i am trying to add dynamic linking support for OCaml
programming
language, but i hit showstopper behavior in the way ld/ELF
combination
works. I will try to outline the source of the problem.

First of all id like to point that OCaml native code backend
is
incapable of producing PIC code, furthermore the functional
nature of
the language will result in much bigger speed degradation in
case of
PIC (accessing functions via PLT etc.) In any case, PIC is
out of the
question. 

OCaml produces assembly output which is later being
processed by as,
final binaries are obtained running ld(gcc in practice).
First problem
is that we obviously need to link DSO's with -Bsymbolic,
since OCaml
adds all sorts of global symbols which are needed for proper
GC
operation, exception handling and whatnot.

======================================================================
Problem No. 1 - Overlapping regions of memory and R_386_COPY
Typical scenario
.data
.global some_data_begin
some_data_begin:

<...>
.global some_data
.type some_data,@object
some_data:
<...>
.size some_data,.-some_data
<...>

.data
.global some_data_end
some_data_end:

The region denoted by some_data{begin,end} is used inside
runtime
system (GC). The problem here is that runtime lives in main
non shared
executable so R_386_COPY is added by ld, which makes all
tests
if (ptr > some_data_begin && ptr <= some_data_end) ... with
ptr =
some_data useless. Even if we add special processing like:

.data
some_data_region=some_data_begin
.type some_data_region,@object
.size some_data_region,some_data_end-some_data_begin

will add nothing to the experience because some_data_region
and
some_data will be separately allocated and overlap will not
be
preserved. 

======================================================================
Problem No. 2 - More R_386_COPY
Almost all data entries emitted by OCaml have special
header:
.data
        .long header_info
        .global label
        .type label,@object
label: 
<...>
        .size label,.-label

using ((long*)label)[-1] in the R_386_COPY environment is
useless.
I think this problem can be solved by modifying the
compiler, but if
there is workaround id like to know about it.

======================================================================
Conclusion:

Even if the above problems are solved and R_386_COPY is
used, size
changes will most likely kill the purpose of shared objects.
So what
i`m after is:

  a) way to omit R_386_COPY completely (more or less what
Jose Luu's
patch http://sources.redhat.com/ml/binutils/2001-06/msg00438.html
was
all about), but at the very least this should be supported
in
_standard_ binutils.

  b) modify the way OCaml operates, still the ELF is very
complicated,
and i need some input on how to do this properly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]