Jeremy White wrote:
> Well, the only reason I would consider submitting a linker script
> for this would be because it will be enabled only by a configure
> script. In fact, that configure option will enable some other
> rather pernicious behaviors (like loading all symbolic info so
> we can write out .DBG files for MS to use).
Linker scripts are ok as long as they are not mandatory (as Alexandre
already said). However, I do not think that you need linker-scripts to
get to the relocation, loader and debug-data. That is already packed in
there at the right location.
> Also, correct me if I'm wrong, but the simplest way to
> hack this with a linker script would be to (shudder) change
> the .text segment to readwrite, because then the previous
> suggestion (Andrews?) would work.
Never ever change the attributes of the .text section unless you are
prepared to write crappy software.
The simple way is to *add* a section just before the .text.
> I'm going to take a stab at this with VirtualAlloc, in the
> hope that ld.so will leave me a crach between .so load addresses.
> (i.e. do a VirtualAlloc of the address immediately prior to
> the load point of the .so).
Hm, the .so should basically load at any address. It is PIC-code and can
therefore be moved throughout the address-space. The bindings are done
through .got and .plt. The load-address in the ELF-object is just a
hint, but not mandatory. So, you will probably not be able to create a
segfault here.
> I'm still holding out hope that there may be a way
> I can trick ld into doing this for me without resorting
> to a linker script.
Actually, you can try to put something in a section that is located
before .text and that is R/W. As I think of it, isn't .plt R/W? It is
located before .text...
Greetings Bertho
