Displaying 6 results from an estimated 6 matches for "planschi".
2020 Jan 08
2
Position independent code writes absolute pointer
...de that I jit/load as position independent code. I have a feeling that it is not possible to solve the issue but I wanted to give it a try.
#include <stdio.h>
int magicValue = 123;
int magicValue2 = 321;
volatile int *pValue = &magicValue;
void printMagicValue()
{
printf("Planschi...\n");
printf("The magic value is %i 0x%p && 0x%p\n", magicValue, &magicValue, pValue);
}
void setMagicValue(int value)
{
magicValue = value;
}
This is the code which I will load as PIC, for the JTMB I use the following settings:
JTMB->setRelocationMod...
2020 Oct 01
2
ORC JIT - different behaviour of ExecutionSession.lookup?
Hey Lang,
Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O<
With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file was loaded by another process – or not.
To understand the MU and MR things better…. I try now to explain the flow of program, when somebody would add an IR file to it – no...
2020 Sep 30
2
ORC JIT - different behaviour of ExecutionSession.lookup?
...all this on Hard Mode. ;)
Yeah it was a silly thought… sorry xO
> The part of your use case that is the most opaque to me is the renaming. When you see a reference to "test" in some object, how do you decide that it should resolve to the definition of "test" in, for example, Planschi, as opposed to some other module? Do you just have a list of modules that you check in-order until you find a matching symbol name?
You wouldn’t find a reference to “test”, you would find “Planschi_test”. We would first try resolving that with the standard C library functions. If this fails, then w...
2020 Sep 29
3
ORC JIT - different behaviour of ExecutionSession.lookup?
Hey Lang,
Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication.
My big problem is still handling cross references between modules with “our” name scheme. Since our old
2020 Sep 24
2
ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup
...ree. This is why I don’t want the LLJIT to do an automatic resolving of those symbols, because it can’t know about our structure. However, how could I achieve this then? Especially if it is not so straight forward to find the symbols that are not resolved yet.
For example: Module A might reference Planschi_test Module B was loaded with name “Planschi” and has a variable called test – so our old loader would then resolve that “Planschi_test” reference with that address.
However those “pathes” can get really complex like navigating to a parent and such.
1. Is there a way then, how I can lookup the...
2020 Sep 23
2
ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup
Hi Lang,
Thank you for your answer! This helped me again a lot!! Also that ResourceTracker is a really neat feature! Looking forward to it! :3
I changed the title cause… there is another issue I have (sorry about that…)
I’m finally allowed to investigate the ORC JIT for integration into our system, which meant I got a few days to actually play around with it. However, another problem arise