similar to: [LLVMdev] Implementing the MC-JIT execution path for ELF, with debugging

2012/1/23 Bendersky, Eli <eli.bendersky at intel.com>: > Hi, > > I would like to examine the implications you mention in more detail. > Thank you! > (1) Symbol address > According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, > st_value is an offset from the

Hi Matt, hi Bruno, I am still struggling to use AVX via MCJIT on TOT... did you succeed yet? I seem to be unable to even get lli to run some code with the "use-mcjit" flag. I attached a test case that works fine for "lli y.bc" but exits with an error for "lli -use-mcjit y.bc": "LLVM ERROR: Unknown object format" If I call InitializeAllTargetMCs() before

Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in

ons 2011-08-31 klockan 10:51 +0200 skrev Ralf Karrenberg: > Hi Matt, hi Bruno, > > I am still struggling to use AVX via MCJIT on TOT... did you succeed yet? > > I seem to be unable to even get lli to run some code with the > "use-mcjit" flag. > I attached a test case that works fine for "lli y.bc" but exits with an > error for "lli -use-mcjit

> Is there an existing method to generate ELF objects with MC on > Windows, without modifying MC? Here "on windows" you mean you want to generate the ELF file with windows-specific code inside? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University -------------- Hi Anton, Yes, what I mean is that I want to generate

> Yes, what I mean is that I want to generate runnable Windows code, on Windows, but package in ELF as the object file. Note that there's absolutely no problem with this approach - in fact we have a functional prototype already. > The reason for this is that I currently want to employ MC-JIT on both Linux and Windows, without implementing two separate runtime dynamic loaders. I want to

Hi, I've been trying to write a tool that reads in an ELF file and modifies one section within that ELF file based on the data contained within another section. Using llvm-objdump as a template of how to read an object file, I've been able to read the latter section that tells me what to edit, but I haven't found a way to edit the former, as everything in the

The existence of tools like Wine, LBW and several MachO loaders on Linux is a good indication that at least in most cases, it's possible to run code packaged in some container format on a system favoring another container. In the worst case, the dynamic loader may explicitly choke on some special features, but empirically it seems that most code can run without problems (we successfully

Hello > Is there an existing method to generate ELF objects with MC on Windows, > without modifying MC? Here "on windows" you mean you want to generate the ELF file with windows-specific code inside? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

While working on some other changes I came across a problem where ELFObjectFile::getSymbolFileOffset was returning a different value than I expected in the case where the symbol in question was a section. Looking at the code, it seems obviously wrong, but I didn't want to just commit my change without at least asking if anyone knew of a good reason for the current behavior. I know there

One other thing that may or may not illuminate the situation. When I run under gdb (on OS X 10.8.3 this is an ancient version of gdb 6.3.5 - but it works with clang compiled C++ code) I get the following error when I try to list a line in dwarf1.lsp: Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle] (gdb)

Hi, I would like to examine the implications you mention in more detail. (1) Symbol address According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's

A mutable interface to object files would be great to have but doesn't exist in any meaningful sense in LLVM today. David's hack and similar tricks are what's necessary right now. I'd love to fix that as its a question that comes up not infrequently. Sent from my iPhone > On Aug 25, 2015, at 2:44 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: >

Ah, now that makes sense. Guess I was a little over-eager with my bugreport. Thanks! :) However, I am now running into the same Problem as Matt ("Target does not support MC emission!"). Best, Ralf Am 25.08.2011 19:32, schrieb Bruno Cardoso Lopes: > Hi Ralf, > > FYI, old JIT doesn't support AVX at all, no encoding info, etc... The > only way to use AVX+JIT is using

I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24). I recompiled debug versions of llvm, clang and my code. I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?). The updated file that

Hello Daniel, thank you very much for the clarification. I confirm that the two libraries showed up without specifying the two configure flags. Cheers, Alberto On Fri, Mar 30, 2012 at 8:48 PM, Malea, Daniel <daniel.malea at intel.com> wrote: > Hi Alberto, > > I can confirm the problem you mentioned, and will look at fixing it. You have indeed stumbled on a bug; the two libraries

On Wed, Oct 12, 2011 at 3:17 AM, Songmao <smtian at ingenic.cn> wrote: > Michael, >    I have rework the patch according to your suggestion.  And I have read > binutil/objdump source code and found that it has a logic that if there's no > symtab, it will use dynsym, which is missing in llvm-objdump. > > Songmao > @@ -747,12 +747,28 @@ error_code

Hi, I've noticed that certain parts of LLVM (RuntimeDyld, JIT) use unaligned memory accesses to load/store pointers or just 32- or 64-bit integers. Technically, this is undefined behavior, and UBSan reports errors when this happens. Even if we believe we're running some x86-specific code (e.g. RuntimeDyldELF::resolveX86_64Relocation) what matters for unaligned acceses in source code is

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks