[llvm-commits] ExecutionEngine move Intercept.cpp

[Danil Malyshev]

Добрый день,

Я вчера целый день не работал, отработаю на неделе и выходных.
Новый RuntimeDyLd почти закончил, думаю, сегодня тебе пришлю патч.

В общем, ситуация такая, по нормальному протащить в RelocationReslover еще и объектный формат не получается, половина динамик линкера туда перекочевывает, и вообще фигня получается, в результате я его убрал.
Сейчас у меня так все работает:
Как и прежде, основная работа идет в общем RuntimeDyLdImpl.
При загрузке объектного файла он сначала загружает и эммитит функции и данные, затем перебирает релокации и для каждой релокации вызывается processRelocationRef(), реализация которого уже лежит в предках: RuntimeDyLdMachO и RuntimeDyLdELF.
Там релокации парсятся и те, которые можно уже сразу разрешить - разрешаются, остальные откладываются до конца загрузки всех символов.

В итоге, в RuntimeDyLdMachO и RuntimeDyLdELF реализованы функции processRelocationRef() и resolveRelocation(), а все остальное в базовом классе.



Теперь, по письму.
Ситуация такая.
У ExecutionEngine есть три наследника: JIT, MCJIT и Interpreter.
У JIT и MCJIT есть функция getPointerToNamedFunction(), но ее нет у Interpreter, поэтому, просто объявить ее виртуальной в ExecutionEngine не получится.
Однако я ее использую в линкере, чтобы получить ссылки на библиотечные функции, такие как printf.
Раньше я делал так: добавил в RuntimeDyLd функцию SetExecutionEngine() и если она вызывалась и EE был установлен, то для поиска функций вызывался EE->getPointerToNamedFunction().
Но раз уж они не хотят переносить getPointerToNamedFunction в ExecutionEngine, то у меня есть следующие варианты:

1. Добавить в ExecutionEngine виртуальную getPointerToNamedFunction, добавить в Interpreter getPointerToNamedFunction всегда возвращающую 0 с каким-нибудь fixme комментарием.
2. В RuntimeDyLd вместо SetExecutionEngine использовать SetMCJIT
3. В RuntimeDyLd вместо SetExecutionEngine добавить что-то вроде SetFunctionFinder, и указатель на функцию, а при создании RuntimeDyLd в MCJIT-е вызывать SetFunctionFinder передавая указатель на MCJIT->getPointerToNamedFunction. В этом случае RuntimeDyLd вообще не будет привязан ни к ExecutionEngine, ни к MCJIT, и кто-то другой, кто будет ее использовать, может сделать свою реализацию поиска функции по имени.

Я пока для простоты сделал второй вариант, но как-то больше склоняюсь к третьему.


С уважением,
Данил


-----Original Message-----
From: Jim Grosbach [mailto:grosbach at apple.com] 
Sent: Saturday, November 12, 2011 3:14 AM
To: Danil Malyshev
Cc: 'llvm-commits at cs.uiuc.edu'
Subject: Re: [llvm-commits] ExecutionEngine move Intercept.cpp

I don't think we want to do this yet. For now, the code is similar, but this will not be the case soon. The MCJIT will almost certainly do things differently. Consider the current code on that side as a placeholder. If, once we have a real solution in place for this part of the MCJIT, there's still lots of commonality, then we can look at combining them.

-Jim

On Nov 11, 2011, at 11:55 AM, Danil Malyshev wrote:

> ping
>  
> From: Danil Malyshev 
> Sent: Friday, November 04, 2011 1:51 AM
> To: 'llvm-commits at cs.uiuc.edu'
> Subject: ExecutionEngine move Intercept.cpp
>  
> Hello everyone,
>  
>  
> Please find attached the patch for review.
> We have 2 similar implementations of getPointerToNamedFunction in MCJIT/Intercept.cpp and in JIT/Intercept.cpp.
> I have re-factored this to move it to the ExecutionEngine so both MCJIT and JIT could use a single implementation.
> Besides, ExecutionEngine looks like a right place for this method.
>  
>  
> Regards,
> Danil
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits