Re: What is exactly read_only_reloc
Re: What is exactly read_only_reloc
- Subject: Re: What is exactly read_only_reloc
- From: Jean-Daniel Dupas <email@hidden>
- Date: Wed, 22 Jul 2009 03:07:25 +0200
Le 21 juil. 09 à 20:45, Terry Lambert a écrit :
On Jul 21, 2009, at 8:35 AM, Jean-Daniel Dupas
<email@hidden> wrote:
Hello,
I'm not sure this is the most appropriate list to ask (and I know
the noise/information ratio is pretty high those days ;-) ) but I'm
hope the ABI specialists here may help me.
Some unix project (with hand-coded asm) require to pass '-
read_only_reloc suppress' to the linker to link as dynamic library.
I wonder what this mean exactly, and what are the drawback of this
flags. I didn't found any information about it, but the ld man page.
And I wonder too if there is a better way to solve this issue (what
may be change in the asm to avoid linker error).
Regards
Jean-Daniel
It won't link as a dynamic library without it because you have
relocations that apparently live in a read-only text segment.
Normally these, if generated by the compiler rather than coded by
hand, would be in a read/write segment mapped copy-on-write, which
is why the man page for ld claims the compiler will never generate
code like this. Without that, you have to suppress so that the page
the relocations are in will get remapped by dyld and modified
anyway, as needed to use them. This has security implications from
two perspectives: (1) since it's in a text page, if the code in the
page has a code signature, you're going to make it invalid by
dirtying the page, and (2) since type of mapping is only
attributable on page boundaries, you're going to open up whatever
also happens to be in the pages with the relocs to also being
modified, along with the relocs themselves. Depending on your exact
use of memory you could also open yourself to stack execution
attacks, etc.. Depending on your code signing enforcement settings,
the code might decide to simply not work and abort fowwing the
mapping change or the page getting dirtied.
The easiest way to deal with relocs is to write your code in C/C++/
ObjC instead of hand-coded assembly. If you must deal with it from
an assembly perspective, you can use assembler directives to move
the relocations into a separate section. The easiest way to know
exactly what to do to do that is to write a short chunk of C code
that does something similar and thinks it's going to live in a
dynamic library so it also has relocs, and then ask the compiler to
generate assembly from the C to see what the compiler does in the
assembly it generates so you can know what to do in yours. Also
realize the contracts between the compiler, assembler, and linker
can and do change over time, so your code will be subject to "bit
rot" any time those move out from under you.
FWIW, unless you are doing unaligned structure assignments or other
cases of degerate code, it's pretty rare these days for a human to
be able to out-code a compiler in assembly at higher optimization
levels, so I was only half-joking about writing the code in C instead.
-- Terry
Thank you very much for this detailed answer.
In fact, this is not my code, this is code from the ffmpeg project.
This is not the first project with ASM I have to deal with, and each
time it brings more trouble than benefit.
C is so close to ASM that I often wonder how hand written ASM could be
"so much faster" than compiled code. Maybe the answer is just that
it's not.
In the previous case, the assembly is used to optimize some codec
(especially H.264). The asm version is faster mainly because it uses
SSE extensions but it can be done in C AFAK. If I have some time, I
will try to follow you advice and to rewrite the annoying function in
C. If there is too much difference between the two versions, there is
something else I would like to try. This is to write a version using
llvm assembly instead of x86 or PPC ASM. It may be interesting to
compare the generated code to the original version. If I understand
correctly, an llvm assembly version can be used to generate either PIC
or non relocatable code. And it would be portable :-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden