similar to: Dumping debug information from BC files

The debug information is actually still in a different format in the .bc file, it is LLVM metadata. I think the best reference for it is here: https://llvm.org/docs/SourceLevelDebugging.html#ccxx-frontend You can dump it just by disassembling the .bc file to textual IR using llvm-dis and examining the !DI* metadata nodes. You will have to run the file through llc to generate an object file to

Thank you for your reply. When I'm running "llvm-readobj" on an .obj file I get a result like shown in my attachment. This is very easy to read. I don't know if this is the codeview format. I would like to get this kind of debug information form a .bc file too, because I JIT them and wanted to try to build a debugger. With the file from "llvm-readobj" I see no

> > 3.) Then I used clang-cl to generate a .bc file - but now I'm not able to > use "llvm-readobj" anymore. Is there any tool available which can dump this > debug information too? > ​.bc is LLVM bitcode [1], not the usual object file. `llvm-readobj` should works only on the latter. ​[1] https://llvm.org/docs/BitCodeFormat.html -- Wei-Ren Chen (陳韋任) Homepage:

I wouldn't be surprised if JITing COFF files on Windows doesn't work so well, since the object file format assumes most symbols are dllimport or within the local 2GB module address range. I'm not familiar with the current JIT state of the art, though. On Thu, Mar 22, 2018 at 1:45 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello, > > I append another clue I

Hello, I append another clue I found out: The problem is definitely not caused by "__ImageBase" the problem comes with the "OFFSET". I generated another object file which crashed. The commonality: mov edx, DWORD PTR ?normalPlanschbecken@@3HA ; normalPlanschbecken lea rcx, OFFSET FLAT :??_C at _0CC@LCMJAIPO at Reading?5?$CCnormalPlanschbecken?$CC?5?$CFi@

Hello Lang, so you are part of the "Jitter-Team"? I'm really interested in this whole jitting-process. I wanted to know, is there a way to load other obj-files, than the one created with clang? Could I load - for example - a obj-File from VisualStudio? Or will the namemangeling fail? Kind regards Björn From: Lang Hames <lhames at gmail.com> To: bjoern.gaier at

> So... there is no way to make throw and catch working in a jitted code > under Windows? > I have used throw and catch in jitted code, so "no way" is too strong. But there's a large range of possible states between "no way" and "always enabled OOTB". Currently, this is pretty close to the "mostly unimplemented" side of the spectrum in LLVM.

Hi Björn, It's correct - I tried casting the virtual function to a regular function. > But I also tried using the virtual function in the normal way. > Yes. If I understand your setup correctly you have a base class, Interface, which is currently compiled into your application, and you are creating a derived class in JIT'd code, and returning an Interface pointer to an instance of

Hi Lang, I'm using Windows. I was parsing an IR-File and added the Module to the ExectuionEngine. If I than searched for a function, I just got 0. But when the module had a main, I got an address. I solved the problem via a call to "generateCodeForModule". The JIT didn't even called my SymbolResolver in this special case. Could you please tell me, if there is a way to

Just to make sure: Both Operatingsystems have the same architecture (x64 or x86)? And in both cases you JIT to the same Architecture? 2018-02-05 16:21 GMT+01:00 via llvm-dev <llvm-dev at lists.llvm.org>: > Hello LLVM-people, > > I have a problem and I hope that you could help me. I'm jitting some .BC > files at runtime with the LLVM under Windows 7. Thanks to the function

Hello LLVM-people, I have a problem and I hope that you could help me. I'm jitting some .BC files at runtime with the LLVM under Windows 7. Thanks to the function " getImageBase()" located in RuntimeDyldCOFFX86_64.h I'm able to support exceptions. But when moving the program to Windows 10, the exceptions will crash the program. I read that the __ImageBase is important for

Seeing the below commit, I wondered whether that's a genuine fix or rather a workaround for a shortcoming in llvm::ScopedPrinter::printNumber. The latter has overloads for [u]int{8,16,32,64}_t, presumably so that it can take arguments of arbitrary integer types. However, at least on recent macOS uint64_t is 'unsigned long long' (and uint32_t is 'unsigned int') while

Hello Lang, I noticed, if I load a obj-File without a main-function, the Jitter won't resolve any address. But if I have a main, everything works fine. Why is this so? Is there a way to stop this? Kind regards Björn Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko

Spoiler: the following only applies to Windows binary format handling. Potential for extending yaml2obj to support COFF debug directories<https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#debug-directory-image-only> recently came up during a code review<https://reviews.llvm.org/D70606#1873185>. Currently, its COFF

Hello everyone, I was following the discussion, but I have to admit, that my skills aren't high enough to follow you guys. For my current exception problem, I don't have to stick around with the PECOFF format, so I used clang to don't compile to a PECOFF, but to a ELF file. Interesting, now I'm missing the functions: __cxa_allocate_exception __cxa_throw _ZTI I loaded the DLL

Still no progress with this problem. Only that non-member functions seems to be working... Also: Even when I set the target triple of the Module (when the file was parsed at runtime) to "COFF" nothing changes... From: Bjoern Gaier/HE/HORIBA To: llvm-dev at lists.llvm.org Cc: cfe-dev at lists.llvm.org Date: 08.02.2018 12:28 Subject: Re: Calling virtual elf functions

Hi Bjoern, CCing cfg-dev (since that's where the conversation started) and llvm-dev (since it's relevant there). Do you know if there is a way to obtain the fully resolved obj-code? I > wanted to load the functions into a shared memory, but how? The only thing > I receive is a function pointer, but I don't know how large the function > 'behind' is. Even a call to

Historically? I implemented support for exceptions back in LLVM 3.3, before LLVM had an implementation of a Windows unwinder. Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable of handling COFF files, and LLVM wouldn't emit the correct sections (with the COFF-formatted unwind tables) when used in ELF mode. The prolog is known to be standard since Julia disables FPO

Pinging this thread to see if anyone else has opinions or objections -- if not I plan to go ahead with stepping towards compatibility with readelf vs llvm-readelf in https://reviews.llvm.org/D54124 on Monday. On Tue, Nov 6, 2018 at 9:52 AM Jordan Rupprecht <rupprecht at google.com> wrote: > Hi James, > > I also wanted to work on this discrepancy, but I just sent a patch instead

Hi all, A broad goal of many of the LLVM binary tools, such as llvm-objcopy and llvm-objdump is to provide an alternative to the GNU equivalent, and as such, these tools have been developed to be command-line compatible. One tool where this hasn’t been the case up to now is llvm-readobj (aka llvm-readelf). There was some discussion in https://reviews.llvm.org/D33872 about the purpose of