[llvm-dev] Position independent code writes absolute pointer
Gaier, Bjoern via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 9 02:34:38 PST 2020
Hey Tim,
Thank you for the answer! I expected something like that sadly :<
However...
> It depends how much control you have over the code. You could instrument code so that it converted all stores of pointers to be relative to some fixed global (PC-relative doesn't work there because it will be loaded at a different address, and "relative to the address it's being stored to" would break memcpy). But that has some major
This sounds interesting from a learning perspective, because I never have done something like that. Is this difficult to do? Also why only convert the stores? Shouldn't I also convert the reads so they are also valid?
Kind greetings
Björn
-----Original Message-----
From: Tim Northover <t.p.northover at gmail.com>
Sent: 09 January 2020 11:08
To: Gaier, Bjoern <Bjoern.Gaier at horiba.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Position independent code writes absolute pointer
Hi Gaier,
There's no way to do this automatically in LLVM at the moment. It sounds kind of related to pointer compression techniques (also not supported right now).
On Thu, 9 Jan 2020 at 08:14, Gaier, Bjoern via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Could it be possible to modify the code on the IR-Level to store PIC/offset address and not absolute address? I’m not familiar with the LLVM IR so I don’t know what is possible and how it effects the code at all.
It depends how much control you have over the code. You could instrument code so that it converted all stores of pointers to be relative to some fixed global (PC-relative doesn't work there because it will be loaded at a different address, and "relative to the address it's being stored to" would break memcpy). But that has some major
issues:
1. It's an ABI break, so you have to be able to recompile all code, including any system libraries you make use of.
2. LLVM can only convert the pointers it knows about, so it would still be broken by someone storing a pointer via an intptr_t cast and probably other things I haven't thought of.
3. There probably isn't even a relocation for any statically initialized pointers. You might be able to convert all of them to use a dynamic module initializer instead though.
4. I'd expect debugging to go horribly wrong.
Cheers.
Tim.
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika
More information about the llvm-dev
mailing list