similar to: [LLVMdev] Why -jit-emit-debug doesn't work with gdb-7.1 ?

On Sat, Jun 19, 2010 at 8:53 PM, Yuri <yuri at rawbw.com> wrote: > I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the > latest release gdb-7.1 (from March 18, 2010) and got this stack: > > (gdb) bt > #0  0x35532156 in ?? () > #1  0x355320f8 in ?? () > #2  0x35532098 in ?? () > #3  0x3553202e in ?? () > #4  0x34a5661a in ?? () > #5  0x349d9bd9

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

Since FreeBSD is an ELF target, this 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

On 06/21/2010 14:14, Reid Kleckner wrote: > Since FreeBSD is an ELF target, this 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,

On Wed, Jul 28, 2010 at 9:01 AM, David Piepgrass <dpiepgrass at mentoreng.com> wrote: >> A LLVM JIT compiler for x86 under 1 MB? I doubt it is possible without >> a major rewriting of LLVM. > > Even with no optimizations? Drat. That means I can't use it. Why? I'd never checked, but I always assumed the LLVM JIT was much larger than 3.4 MB. For comparison: [rnk at

> Why do you care about the size of library files? I assumed dynamic libraries and static libraries were similar in size, but I just checked some of my own static libraries and they are indeed much larger than the executables they compile to. Sorry, it just never occurred to me that they would be much different. > > Anyway, in the same example I mentioned that the size of HowToUseJIT

David Piepgrass <dpiepgrass at mentoreng.com> writes: >> Comparing the size of the static libraries makes little sense, and even >> less when they are compiled by different tools. What really matters is >> the size of the executables. >> >> I agree that LLVM can be considered a heavyweight dependency on this >> aspect. > > Why is the size of static

I have this situation when the same code SEGVs in JIT with option -disable-fp-elim and works fine without it. How can this possibly happen? Is it possible that there is a bug in JIT that stack isn't properly lowered for local variables when prologs are present? Or maybe JIT can accidentally use ebp for some values when it's supposed to be only used by frame pointer value. Stack (see

On Mon, Jun 21, 2010 at 5:14 PM, Yuri <yuri at rawbw.com> wrote: > 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/lib/libLLVM-2.8svn.so > Load new symbol table from > "/usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so"? (y

You said this is on 32-bit x86? My understanding is that in that case, gdb will use ebp/esp to unwind the stack and doesn't need dwarf. It may have different behavior on FreeBSD if frame pointers are normally omitted on that platform. gdb ignores them on Linux x86_64 because they are generally omitted. This might actually be the best explanation for your symptoms, since this is what a gdb

Hi There, We have a couple open positions for Rails developers in Marin County, just across from Golden Gate Bridge from San Francisco. For a variety of reasons, we''d prefer folks from a Java background, but mostly we need smart, agreeable, disciplined, and self-directed. Here''s the full job description. Please use the address at the end of the message rather than