On Friday 07 March 2008 Ian Lance Taylor wrote:
> "Philipp Marek" <[EMAIL PROTECTED]> writes:
> >> Shouldn't this be done in the linker instead?
> >
> > Well, can the linker change the instruction sequences? Ie. put a JMP
> > instead of other code?
>
> Sure. The linker can do whatever it likes. The usual problem is that
> by the time the linker sees the code, it no longer knows about PC
> relative references within the same section. So if you have
>
> call foo
> ...
> sequence to remove
> ...
> foo:
>
> and the call is PC-relative, then when the linker removes the sequence
> of instructions it will not know that it needs to adjust the call to
> foo.
Right.
> What you are describing is a type of linker relaxation, and the same
> issues arise there. The usual solution is to force the assembler to
> emit all PC-relative relocations, so that the linker knows about them
> and is able to adjust them.
But what we'd need above is to have the compiler make a reference to
[removed_sequence + offset] instead, and that could be done by the linker
again.
So when the compiler removes a piece of code by a "jump <symbol>", it can use
offsets in there as usual.
> Linker relaxation is used routinely in special sections, such as the
> .eh_frame section used to hold stack unwind information for throwing
> exceptions. It is also used for code sequences on some processors,
> but normally not on the i386/x86_64.
Thank you very much for this information!
Another idea: if we find out that such sequences are *very* common (eg. by
comparing many different binaries and libraries), libc (or a libcommon or
something like that) could have a set of these "abbreviations" - eg. indexed
by symbol, which is defined as MD5_hex(removed section).
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
