similar to: [LLVMdev] Assembling the output of llc

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Assembling the output of llc"

2008 May 19
1
[LLVMdev] Assembling the output of llc
On May 18, 2008, at 11:51 PM, Talin wrote: > Anton Korobeynikov wrote: >> Hello Talin, >> >>> Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I >>> assumed that it would choose sensible defaults... >>> >> Could you please provide a .bc testcase? There can be multiple >> issues, >> but at the first glance it
2010 Aug 24
1
[LLVMdev] non_lazy_ptr question
So, I've got a case where I am attempting to pass the address of a static symbol from a module written in Tart (the language I am working on), to a module written in C (which is part of Tart's runtime library). This works fine on Linux, but fails on OS X because the address being passed is the "non_lazy_ptr" symbol, not the symbol itself. In my .bc file, I've got code that
2008 May 17
2
[LLVMdev] Assembling the output of llc
Hello, > get tons of errors - it appears to be choking on lines like the following: What is the target you're generating code for? Actually, not target (which seems to be x86), but subtarget? Is it darwin? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
2008 May 18
2
[LLVMdev] Assembling the output of llc
Hello Talin, > Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I > assumed that it would choose sensible defaults... Could you please provide a .bc testcase? There can be multiple issues, but at the first glance it seems, that names were not properly mangled. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg
2008 May 19
0
[LLVMdev] Assembling the output of llc
Anton Korobeynikov wrote: > Hello Talin, > >> Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I >> assumed that it would choose sensible defaults... >> > Could you please provide a .bc testcase? There can be multiple issues, > but at the first glance it seems, that names were not properly mangled. > I've created bug
2011 Oct 16
2
[LLVMdev] Static destructor problem with recent HEAD
On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"
2011 Apr 07
1
[LLVMdev] More DWARF problems
On Apr 7, 2011, at 12:14 PM, Talin wrote: > > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] =
2011 Oct 16
0
[LLVMdev] Static destructor problem with recent HEAD
Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +
2010 Oct 10
1
[LLVMdev] More questions about non_lazy_ptr
I have a problem where my LLVM-generated code works on Linux but not on OS X, and the problem involves non_lazy_ptr. I have an external symbol named "@gc_safepoint_map", which is generated by the linker's GCStrategy plugin. Since it is not generated until link time, I declared it as an external symbol so that the modules that use it can compile without error. Here's what the
2010 Oct 23
2
[LLVMdev] Cast failure in SelectionDAGBuilder
I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*
2010 Aug 29
0
[LLVMdev] "Cannot fine DIE"
On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > >> >> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >> >>> I recently started getting this error when I try to debug my >>> LLVM-compiled program in GDB:
2011 Jul 26
3
[LLVMdev] Linking opaque types
On Jul 25, 2011, at 10:58 PM, Talin wrote: > To handle the fact that types do not (and can not, at least as long as we intend to support obscure languages like "C" :) have linkage, the the linker uses a "best effort" approach. It attempts to merge types and rewrite IR to use the merged types where it can, but it doesn't make any guarantees. > > I want to add an
2010 Nov 09
2
[LLVMdev] Next round of DWARF issues/questions
On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,
2010 Sep 25
2
[LLVMdev] Strange exception in SelectionDAGBuilder
I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {
2010 Nov 26
3
[LLVMdev] Next round of DWARF issues/questions
On Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > > > On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> > dpatel at apple.com> wrote: > >> >> On Nov 6, 2010, at 7:35 PM, Talin wrote: >> >> After to speaking to Devang
2011 Apr 03
2
[LLVMdev] More DWARF problems
On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > > I've been trying to track down the problem with the DWARF info that is > being emitted by my front end, which has been broken for about a month now. > Here's what happens when I attempt to use gdb to debug one of my programs on > OS X:
2010 Nov 09
0
[LLVMdev] Next round of DWARF issues/questions
On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > >> After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now
2010 Nov 07
3
[LLVMdev] Next round of DWARF issues/questions
After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. However, I'm also seeing a lot of new problems which weren't exposed before. After spending the better part of two
2010 Nov 08
0
[LLVMdev] Next round of DWARF issues/questions
On Nov 6, 2010, at 7:35 PM, Talin wrote: > After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. > > However, I'm also seeing a lot of new problems which
2010 Sep 26
0
[LLVMdev] Strange exception in SelectionDAGBuilder
Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a