search for: getelfwriterinfo

...are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo or getELFWriterInfo, and returns a corresponding FileModel enum value. llc's main function uses the resulting FileModel value to determine which of the {AddMachOWriter,AddELFWriter} functions to call. This is limiting for a number of reasons: 1. If a given platform (e.g. x86) may support both MachO and ELF, Mach...

the reason I built llvm with vc is that I am familiar with vc. At first i also thing that build llvm with MingW will solve this problem. but after I read the source code void JITDebugRegisterer::RegisterFunction(const Function *F, DebugInfo &I) { // TODO: Support non-ELF platforms. if (!TM.getELFWriterInfo()) return; ...... } I thing MinGW is helpless with debug jit on win. getELFWriterInfo returns true only on linux ,and the RegisterFunction gen symbol infomation only on linux. 2011/6/7 ��f�� <chenwj at iis.sinica.edu.tw>: >> so as you said , there is no hop for debug jit on windows...

...d allow inlining of writting functions in X86CodeEmitter and other emitters. They would have to be templated and the MCE member parameterized. > LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the > derived backend TargetMachine implements one of getMachOWriterInfo or > getELFWriterInfo, and returns a corresponding FileModel enum value. > > llc's main function uses the resulting FileModel value to determine > which of the {AddMachOWriter,AddELFWriter} functions to call. > > This is limiting for a number of reasons: > 1. If a given platform (e.g. x86) may supp...

...writting functions in X86CodeEmitter and other emitters. They would have > to be templated and the MCE member parameterized. > >> LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the >> derived backend TargetMachine implements one of getMachOWriterInfo or >> getELFWriterInfo, and returns a corresponding FileModel enum value. >> >> llc's main function uses the resulting FileModel value to determine >> which of the {AddMachOWriter,AddELFWriter} functions to call. >> >> This is limiting for a number of reasons: >> 1. If a given plat...

so as you said , there is no hop for debug jit on windows? 2011/6/7 ��f�� <chenwj at iis.sinica.edu.tw>: > Hi, Tang > >> but in the source code i find this comment. >> // ELF is a reasonably sane default and the only other X86 targets we >> // support are Darwin and Windows. Just use "not those". > > I guess you found above comment in

> so as you said , there is no hop for debug jit on windows? I have no idea. Maybe someone familiar with LLVM on Windows can answer your question. But I have a question for you, you said you built LLVM with Visual Studio and debugged your program with GDB. I doubt the Visual Studio produces the debugging information recognized by GDB. Why not build LLVM with MinGW or someting like that?

On Fri, Oct 26, 2012 at 6:01 PM, 陳韋任 (Wei-Ren Chen) < chenwj at iis.sinica.edu.tw> wrote: > Hi Jan, > > Why do you think TargetELFWriterInfo is not used (IIUC)? > I see a lot of targets inherit class TargetELFWriterInfo > for their ELF writer. > > Yes, a lot of targets inherit it, but it looks like nothing ever calls getELFWriterInfo() (anymore) to get access to the instances. > Regards, > chenwj > > -- > W...

...is should work fine. I've also tested that this works in 32-bit by building gdb and llvm in 32-bit mode and testing this stuff while running on a 64-bit OS. I would try setting a breakpoint in gdb on 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being called, and that getELFWriterInfo returns something. If that function actually installs the code entry, then it's a gdb problem. Reid On Mon, Jun 21, 2010 at 12:49 PM, Yuri <yuri at rawbw.com> wrote: > On 06/21/2010 11:14, Reid Kleckner wrote: >> >> Yes, I have some version of 7.1 installed on my worksta...

On 06/21/2010 11:14, Reid Kleckner wrote: > Yes, I have some version of 7.1 installed on my workstation and it works for me. I repeted what you did step by step and it still doesn't work for me, see log below. Two differences: I am on FreeBSD and it's 32 bit. It's svn revision 105825. Plus I have few unrelated patched applied to it which shouldn't matter. Yuri $ lli

...ing functions in X86CodeEmitter and other emitters. They would > have > to be templated and the MCE member parameterized. > >> LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the >> derived backend TargetMachine implements one of getMachOWriterInfo or >> getELFWriterInfo, and returns a corresponding FileModel enum value. >> >> llc's main function uses the resulting FileModel value to determine >> which of the {AddMachOWriter,AddELFWriter} functions to call. >> >> This is limiting for a number of reasons: >> 1. If a given plat...

Perhaps it could have been removed when ELFWriter was removed in r147615? http://llvm.org/viewvc/llvm-project?view=rev&revision=147615 - Jan On Fri, Oct 26, 2012 at 4:41 PM, Jan Voung <jvoung at chromium.org> wrote: > Oops, sorry hit send too early -- meant to just make a draft email. I'm > still looking through, but so far I hadn't seen many of its methods being >

Hi Jan, Why do you think TargetELFWriterInfo is not used (IIUC)? I see a lot of targets inherit class TargetELFWriterInfo for their ELF writer. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chen...

2012/10/27 Jan Voung <jvoung at chromium.org>: > On Fri, Oct 26, 2012 at 6:01 PM, ��f�� (Wei-Ren Chen) > <chenwj at iis.sinica.edu.tw> wrote: >> >> Hi Jan, >> >> Why do you think TargetELFWriterInfo is not used (IIUC)? >> I see a lot of targets inherit class TargetELFWriterInfo >> for their ELF writer. >> > > Yes, a lot of targets inherit it, but it looks like nothing ever > calls getELFWriterInfo() (anymore) to get access to the instances. > Via greping, I find...

...e also > tested that this works in 32-bit by building gdb and llvm in 32-bit > mode and testing this stuff while running on a 64-bit OS. > > I would try setting a breakpoint in gdb on > 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being > called, and that getELFWriterInfo returns something. If that function > actually installs the code entry, then it's a gdb problem. > I am on FreeBSD and gdb-7.1 seems to be broken. It fails to set breakpoints in shared libs. using symbol-file causes this message: (gdb) symbol-file /usr/local/llvm/svn-r105825.dbg/l...