similar to: [LLVMdev] Debugging Status on x86?

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 support is concerned? > The behavior I am

Hi Eli, thanks for 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

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 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

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.

> 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

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 level hammer to do ballpeen > work..... But when in Rome.... :-)

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 to gold might be an effective work-around. Jay.

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 rebase -i", which

Hi everyone, Rafael has graciously given me some pointers for helping out on the ARM/MC .s emission infrastructure, and I am volunteering to do so. It looks like as of yesterday, the MC obj emitter for ARM is also incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for example) So if anyone already has started looking into this, I'd like to pool info so as to not step on toes. Any

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 to print the rest of the file. I can't think of an example

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 LIT tests that checked the IR and Dwarf and GDB

On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: > Hi All, > DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs > to encode debugging information. We are replacing this interface with new > simple interface, DIBuilder. > Here is one example that demonstrates differences between two interfaces. To > create debug information

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? Thanks -jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110806/e7e717ef/attachment.html> -------------- next part --------------

On Sun, Jul 24, 2011 at 9:54 AM, FlyLanguage <flylanguage at gmail.com> wrote: > Lot of good points. > > > Yep, switching to git would require a lot of work on the project > > maintainers' side. Commit hooks, setting up repositories, rewording > > policies in terms of the commands of the new tools, and that only to > > regain the status the project already

Lot of good points. > Yep, switching to git would require a lot of work on the project > maintainers' side. Commit hooks, setting up repositories, rewording > policies in terms of the commands of the new tools, and that only to > regain the status the project already has - [...] All of which could be done on a mirror, with pushes to svn during the transition. Once it can be

Hi All, DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs to encode debugging information. We are replacing this interface with new simple interface, DIBuilder. Here is one example that demonstrates differences between two interfaces. To create debug information entries to encode volatile type one would use following call in a language front end,

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

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

-llvmcommits On Mon, Jan 10, 2011 at 3:21 PM, Renato Golin <renato.golin at arm.com> wrote: > Btw, I know this is for ELF printing, but can the same infrastructure > you're using to print the hi/lo be used to print relocation in Asm > output? Or is this a completely separate subject? Hi Renato, If I am understanding you correctly, then the answer is no, because .s output