On 2012-08-18 10:20:17 +0000, "Jacob Carlborg" <[email protected]> said:
On Saturday, 18 August 2012 at 01:06:10 UTC, Michel Fortin wrote:
In the original linked article (which I wrote) what was proposed was to
have the dynamic linker calculate offsets for fields and vtable entries
and insert those offsets directly in the code (just like a linker does
when it resolves symbols). But for that you'd need a custom linker
(both static and dynamic), and probably a custom shared library format.
So it's a huge task, especially when you consider that it should run on
multiple platforms. But this same approach could make the C++ ABI
non-fragile too.
I'm having a hard time to see why a regular application couldn't do
this, i.e. druntime. I'm mostly familiar with Mac OS X and seems pretty
easy just to access the running executable and change what you want in
it. That's what the dynamic linker is doing anyway. There's even a flag
for object files indicating it's a dynamic linker (don't know if that
is used any more). Sure it would probably break easily if the runtime
of the OS changed (new version of the dynamic linker, something
changing the object format).
Using a lookup table it could be done.
But if you're going to patch the code as a dynamic linker does but
after the dynamic linking stage, then you'll have to play around with
no-execute flags as well as address layout randomization, and this is
going to be ugly.
Speaking of OS X, if your app is sandboxed I think it won't be able to
do anything like that. Given that sandboxing is the beginning of a
trend on many platforms, I'm not sure implementing all that would be
worthwhile: all it'd accomplish is make processes that can't be
sandboxed run a little faster.
--
Michel Fortin
[email protected]
http://michelf.ca/
