This is the mail archive of the binutils@sourceware.cygnus.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]

Behaviour change from ld 2.9.1 to ld 2.9.5 (fwd)


Hello Lorenzo,
   Here is one solution to your problem.

1) Start with the linker script elf_i386.x, from the binutils you are
   using.  It's unwise to use an old script, and expect it to work without
   modification on a newer binutils.  I'm assuming this linker script is
   like the current CVS binutils in that it doesn't have a PHDRS
   specification.

2) Replace the line ". = 0x08048000 + SIZEOF_HEADERS;" with
   ". = 0x08048000 + 1024;"  You can't use SIZEOF_HEADERS in fancy ld
   scripts, which is arguably a linker bug.  The 1024 should be large
   enough for most cases;  Your test program only requires 224 header
   bytes.

3) Add your extra output section before this line as you did before.  You
   could also put it right at the end as long as you replaced "*(COMMON)"
   in the .bss output section specification with 
   "*(EXCLUDE_FILE (aux1.o) COMMON)"

An alternative would be to correctly specify a separate phdr in PHDRS for
your extra output section, but I haven't tested this.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

---------- Forwarded message ----------
Date: Sun, 07 May 2000 09:32:32 +0200
From: Lorenzo Campedelli <lorenzo.campedelli@libero.it>
To: Alan Modra <alan@linuxcare.com.au>
Subject: Behaviour change from ld 2.9.1 to ld 2.9.5

Hello,
    I have a problem I assume related to ld, I hope you can help me.

I wrote a program which  simulates an embedded system, where some memory
areas access permissions, or even their availability are variable at
runtime, depending, for instance, on the running task (some tasks use a
different LDT, by the simulated OS point of view).

The implementation depends on being able to place some global variables,
let's say the COMMON section from some object files, at a specific
memory
address (e.g. 0x50000000).
This is needed in order to have the variables allocated in a private
shared memory segment and thus to able to change the access permissions
at runtime, or even mapping the same memory twice in memory with
different permissions.

While using ld 2.9.1 (rh5.2 up to rh6.1) I was able to obtain that setup
by means of a modified ld script, defining new sections, placing them at
the desired address, and declaring some object files inside them solved
the problem.

When I switched to ld 2.9.5 (rh6.2) the trick stopped working. The
program is still linked, but the produced executable SEEMS enormous
(~ 1.5 Gb instead of 2 Mb) and its execution gives :

[campedel@betelgeuse ld]$ ./ld_prova
Segmentation fault (core dumped)

if run from gdb :

(gdb) r
Starting program: /home/campedel/misc/prova/ld/ld_prova
warning: Cannot insert breakpoint -1:
Cannot access memory at address 0x4000af20

This seems to be caused by the new section being placed at an offset
0x50000000 inside the executable file.

Attached you can find a very little program reproducing the described
behaviour.
Let me know whether you would like to have some more information.

Do you think this can depend on changed behaviour from 2.9.1 to 2.9.5 ?
If yes, is there anything I can do in order to obtain the needed
behaviour from the new version ?
By the way, is there another way to place a variable at a desired memory
address ?

Thanks in advance for any help you will provide.

P.S. : Please CC to me as I'm not currently subscribed to this list, by
       the way, is there an archive available on-line ?

Best Regards
    Lorenzo Campedelli

ld.tgz


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