search for: jasonwkim

...---------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110806/e7e717ef/attachment.html> -------------- next part -------------- dreadstar:x86_64-Linux2:~/Work/hg-llvm/BUILD/llvm-gcc-4.2-rw/gcc>strace -f -s 1600000 -e trace=process /home/jasonwkim/Work/hg-llvm/BUILD/llvm-gcc-4.2-rw/./gcc/xgcc -B/home/jasonwkim/Work/hg-llvm/BUILD/llvm-gcc-4.2-rw/./gcc/ -B/pkgs/llvm-gcc-4.2-rw/x86_64-unknown-linux-gnu/bin/ -B/pkgs/llvm-gcc-4.2-rw/x86_64-unknown-linux-gnu/lib/ -isystem /pkgs/llvm-gcc-4.2-rw/x86_64-unknown-linux-gnu/include -isystem /pkgs/llvm-g...

Jason Kim <jasonwkim at google.com> writes: > I believe git has a similar system for maintaining "branches of patches"  A pointer/tutorial on how to do this would be most welcome. -Dave

Hi everyone, I was under the impression that debugging support on llvm-gcc-4.2.1 + llvm-2.7 was pretty complete (at least on x86 linux), but ran into a glitch. First off, are there any docs that discuss the current state, in so far as DWARF support is concerned? The behavior I am seeing is the following: llvm-gcc -g hello.c -o hello produces a working executable with apparently complete

Is the rationale that llvm has matured/advanced to the point where integration tests are the only ones to make sense from a test density perspective? On Thu, Sep 16, 2010 at 5:05 PM, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > > I am trying to get up to speed on the MC object file emission for ARM, > the first cut being for ELF, and the testing required for that. > > Obviously, we want the tests for the .o emission to ultimately test > the entire .ll -> ma...

Hi everyone, I am trying to get up to speed on the MC object file emission for ARM, the first cut being for ELF, and the testing required for that. Obviously, we want the tests for the .o emission to ultimately test the entire .ll -> many llvm passes -> .bc -> .o, but as a first cut, my instinct tells me that a simple .cpp unit tests that directly invokes the MC code to generate (and

On Thu, Aug 5, 2010 at 6:22 PM, Jason Kim <jasonwkim at google.com> wrote: > > Hi everyone, > I was under the impression that debugging support on llvm-gcc-4.2.1 + > llvm-2.7 was pretty complete (at least on x86 linux), but ran into a glitch. > First off, are there any docs that discuss the current state, in so far as > DWARF sup...

...your response. AFAIK, Removing -g from the second call to gcc does not seem to do anything. The generated executable shows the same behavior under gdb. -jason On Thu, Aug 5, 2010 at 6:31 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Aug 5, 2010 at 6:22 PM, Jason Kim <jasonwkim at google.com> wrote: > > > > Hi everyone, > > I was under the impression that debugging support on llvm-gcc-4.2.1 + > > llvm-2.7 was pretty complete (at least on x86 linux), but ran into a > glitch. > > First off, are there any docs that discuss the current stat...

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high leve...

On 6 August 2011 23:05, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > -r136747 of llvm-gcc (and possibly others) is apparently tickling a binutils > issue on linux x86-64 > Has anyone seen anything like this? Yes, it looks like this: http://sourceware.org/bugzilla/show_bug.cgi?id=12887 I think switching from ld...

dag at cray.com (David A. Greene) writes: > Jason Kim <jasonwkim at google.com> writes: > >> I believe git has a similar system for maintaining "branches of patches"  > > A pointer/tutorial on how to do this would be most welcome. It depends on the definition of "branches of patches" ;-). I manage my patches with "git...

2010/10/21 Jason Kim <jasonwkim at google.com>: > That is exactly what I need - I need a nice MC way to output a at > least two different 4 byte size fields after all of the blobs in the > .ARM.attributes are sent out. Hi Jason, If I got it right, you need to write to the attributes section after you have moved out...

...Object File Library. llvm-nm changed to match binutils-nm > for COFF and ELF (32, little endian). (Michael Spencer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Sep 2010 10:02:55 -0700 > From: Jason Kim <jasonwkim at google.com> > Subject: Re: [LLVMdev] ARM MC .s status? > To: Rafael Espindola <espindola at google.com> > Cc: nacl-eng <nacl-eng at google.com>, llvmdev at cs.uiuc.edu > Message-ID: > <AANLkTim9uxEe+ktRXr1N2v3f_X7u3q1WQ8Ag5N_YuwLN at mail.gmail.com<AANL...

On 24 February 2011 21:34, Jason Kim <jasonwkim at google.com> wrote: > On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: It simplified a bit type construction but the overall code did not reduce that much. It's still very similar to the previous style but had a few differences in the IR output. We had...

---------- Forwarded message ---------- From: Jason Kim <jasonwkim at google.com> Date: Fri, Oct 22, 2010 at 12:59 PM Subject: Re: [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes To: Rafael Espíndola <rafael.espindola at gmail.com> On Fri, Oct 22, 2010 at 12:51 PM, Jason Kim <jasonwkim at google.com>...

> Also what is the preferred method for MC way of setting out subsection > sizes after the fact? I am guessing I need to use an MCFixup? > How do I get an MCExpr to evaluate a method for the subsection size? > Is there an equivalent use in the places using MCFixup? > Do I need to add a new subclass to MCExpr for doing this? > > JimG, can you please comment on the MachO

...started looking into this, I'd like to pool info so as to not step on toes. Any add'l tips and pointers would be greatly appreciated. Thanks! -jasonkim On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at google.com> wrote: > On 13 September 2010 17:36, Jason Kim <jasonwkim at google.com> wrote: >> Hi Rafael, hope things are well. >> >> Sehr suggested I ping you briefly on suggestions/ideas/steps for >> contributing to the MC/ARM code base - >> Any hints/breadcrumbs would be greatly appreciated. > > Sure. CCing nacl-eng in case t...

...rink! :-) Thanks for reading! -jason p.s. YES! I'm not crazy! Wo0T! ---------- Forwarded message ---------- From: Rafael Espindola <espindola at google.com> Date: Tue, Sep 21, 2010 at 7:49 AM Subject: Re: [llvm-commits] Fwd: Initial cut of ARM MC ELF emitter (PATCH) To: Jason Kim <jasonwkim at google.com> Cc: llvm-commits at cs.uiuc.edu On 20 September 2010 16:45, Jason Kim <jasonwkim at google.com> wrote: > Apologies once again. The whitespace issue in arm-mc-elf-s01.patch4 > has been fixed. Hello Jason. With this patch I got the following failures in "make che...

So far, for X86 identical ELF relocation flags show up in include/llvm/Support/ELF.h and lib/Target/X86/X86ELFWriterInfo.h Not to mention, there are two different files named ELF.h ./lib/CodeGen/ELF.h ./include/llvm/Support/ELF.h I'd think the latter should be renamed MCELFSupport.h Thanks! -jason

On 22 November 2010 20:52, Jason Kim <jasonwkim at google.com> wrote: > So far, for X86 identical ELF relocation flags show up in > > include/llvm/Support/ELF.h and > lib/Target/X86/X86ELFWriterInfo.h > > Not to mention, there are two different files named ELF.h I would say that ELF.h should be the canonical one. > ./li...

Hi everyone, happy new year. This note is to announce that support for PC relative reloc tags for movw/movt is nearing completion (hopefully <48hrs!). This work is is from Jan Voung, David Meyer and myself. Unfortunately, to test this change, we need to patch ARM/AsmParser to address http://llvm.org/bugs/show_bug.cgi?id=8721 Locally, we have hacked up a solution to 8721, but its not ideal