llvm dev - Apr 2017 - Relocation design of different architecture

Hi,
Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the header
files included for different architectures like RuntimeDyldCOFFX86_64.h or
RuntimeDyldCOFFI386.h etc, what is the connection of these files for
relocation and linking as the linking and relocation for diff architecture
is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp  and it doesn't use any
function from these header file except the processRelocationRef(). The
header files in Targets/ also handles exceptions, so what is the need for
that in relocation and linking process ? Also please help with what this
processRelocationRef() actually does ? . Please guide.

sincerely,
Siddharth
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170420/fcfa0634/attachment.html>

The x86_64 and i386 architectures have different actual relocation records.
So if you build code for i386, you need one processRelocationRef() function
(handling the relevant relocations in that model), and when producing code
for x86_64, there are different relocation records. The two files contain
the derived form of the class that processes the relocation records when
dynamically loading JITed code in LLVM - mainly implementing the two
different forms of symbol entries that refer to the relocations - i386 uses
COFF::IMAGE_REL_I386_*, in x86_64 the relocation types are
COFF::IMAGE_REL_AMD64_*.

Conceptually, they do the same thing, it's the details of exactly how and
where the relocation ends up and how it's recorded by the linker that
differs.

Theoretically, one could probably construct a loadable file that doesn't
care what architecture it is for, but it would end up with a lot of
redundant & overlapping functionality, and the code to handle every
different architecture in one huge switch-statement would be rather complex
(and long!). So splitting the functionality per architecture helps make the
code clear.

If you need further help to understand the code, you'll probably need to
ask a more concrete question, as it is probably not possible to describe
all the relevant information on this subject in less than 200 pages, never
mind a simple email-thread.

--
Mats

On 20 April 2017 at 11:13, Siddharth Shankar Swain via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
> Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the header
> files included for different architectures like RuntimeDyldCOFFX86_64.h or
> RuntimeDyldCOFFI386.h etc, what is the connection of these files for
> relocation and linking as the linking and relocation for diff architecture
> is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp  and it doesn't use
any
> function from these header file except the processRelocationRef(). The
> header files in Targets/ also handles exceptions, so what is the need for
> that in relocation and linking process ? Also please help with what this
> processRelocationRef() actually does ? . Please guide.
>
> sincerely,
> Siddharth
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170420/0de7f573/attachment-0001.html>

Thanks for the reply. I was just asking about in general whatever header
files are there in Targets/ for different architectures are not including
any function except this processRelocationRef() to be used in
RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp and i
think these files are the ones which are actually doing the relocation and
linking work. So what purpose do these header files inside Targets/
actually serve. Also they include exception handling in form of exception
frames, So can u guide on this issue ?

Thanks,
Siddharth

On Thu, Apr 20, 2017 at 4:02 PM, mats petersson <mats at
planetcatfish.com>
wrote:
> The x86_64 and i386 architectures have different actual relocation
> records. So if you build code for i386, you need one processRelocationRef()
> function (handling the relevant relocations in that model), and when
> producing code for x86_64, there are different relocation records. The two
> files contain the derived form of the class that processes the relocation
> records when dynamically loading JITed code in LLVM - mainly implementing
> the two different forms of symbol entries that refer to the relocations -
> i386 uses COFF::IMAGE_REL_I386_*, in x86_64 the relocation types are
> COFF::IMAGE_REL_AMD64_*.
>
> Conceptually, they do the same thing, it's the details of exactly how
and
> where the relocation ends up and how it's recorded by the linker that
> differs.
>
> Theoretically, one could probably construct a loadable file that
doesn't
> care what architecture it is for, but it would end up with a lot of
> redundant & overlapping functionality, and the code to handle every
> different architecture in one huge switch-statement would be rather complex
> (and long!). So splitting the functionality per architecture helps make the
> code clear.
>
> If you need further help to understand the code, you'll probably need
to
> ask a more concrete question, as it is probably not possible to describe
> all the relevant information on this subject in less than 200 pages, never
> mind a simple email-thread.
>
> --
> Mats
>
> On 20 April 2017 at 11:13, Siddharth Shankar Swain via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>> Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the
>> header files included for different architectures like
>> RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the
>> connection of these files for relocation and linking as the linking and
>> relocation for diff architecture is done in RuntimeDyldELF.cpp,
>> RuntimeDyldCOFF.cpp  and it doesn't use any function from these
header file
>> except the processRelocationRef(). The header files in Targets/ also
>> handles exceptions, so what is the need for that in relocation and
linking
>> process ? Also please help with what this processRelocationRef()
actually
>> does ? . Please guide.
>>
>> sincerely,
>> Siddharth
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170420/1d4310d6/attachment.html>