[llvm-dev] Relocation design of different architecture

[mats petersson via llvm-dev]

Basic Object Oriented design uses a derived class to implement a
functionality of the generic case. It's the same basic principle as:

class Animal
{
    void virtual Say() = 0;
};

class Cat: public Animal
{
    void Say() override { cout << "Meow!" << endl; }
}

class Dog: public Animal
{
    void Say() override { cout << "Woof!" << endl; }
}

class Fish: public Animal
{
    void Say() override { cout << "Blub!" << endl; }
}

In this case, different types of COFF-architectures use different
relocation entries, and based on the architecture, a specific
implementation of the RelocationDyldCOFF class is created to perform the
relocation.

See http://llvm.org/docs/doxygen/html/classllvm_1_1RuntimeDyldCOFF.html for
a class diagram of how this is done.

The generic code in RuntimeDyld*.cpp only knows that relocations exists,
and that they need to be dealt with. Not HOW to actually perform the
relocation - just like "Animal" doesn't know what a cat or a dog "says".
The processRelocationRef() is called here:
http://llvm.org/docs/doxygen/html/RuntimeDyld_8cpp_source.html#l00251

Again, it's not clear exactly what you are asking for, so I'm not sure
whether my explanation is helpful or not...

--
Mats


On 20 April 2017 at 12:05, Siddharth Shankar Swain <
h2015096 at pilani.bits-pilani.ac.in> wrote:

> 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/777c03be/attachment.html>