similar to: [LLVMdev] codeview debug info in Visual Studio

Hi Carlo, Do you have VS2010 handy? It should read the DI fine. Unfortunately, VS2013 is not able to use the debug info we generate. It is on my plans to investigate and fix the generator, but I didn't have enough free cycles recently. -- Tim 2014-09-15 20:30 GMT+04:00 Reid Kleckner <rnk at google.com>: > +Timur > > Hm, this didn't work out of the box for me. > >

On Mon, Sep 15, 2014 at 10:11 AM, Carlo Kok <ck at remobjects.com> wrote: > > I think I have VS2010 somewhere yes. Any hints on where to find this > problem so I can try to solve it myself? > Sure, llvm/lib/CodeGen/AsmPrinter/WinCodeViewLineTables.cpp -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Mon, 15 Sep 2014 19:33:42 +0200, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Basically, see my patches to LLVM from early 2014 -- they include tests, > a DI generator and a DI dumper. I'd be happy to review your patches too! Thanks. Looks like it's likely that it's one of the 0xF1 sections, the first one always has the object file name and what seems

RFC: CodeView debug info emission in Clang/LLVM Overview On Windows, the de facto debug information format is CodeView, most commonly encountered in the form of a .pdb file. This is the format emitted by the Visual C++, C#, and VB.NET compilers, consumed by the Visual Studio debugger and the Windows debugger (WinDbg), and exposed for read-only access via the DIA SDK. The CodeView format has never

Attached is a slightly updated patch. (it doesn't include D2222 yet). 2013/11/19 Eric Christopher <echristo at gmail.com>: > In general I do think we're going to need to abstract it out as much > as possible. I'm not sure what the previous patch looks like, but > abstracting the interface out would be general goodness for this. We > can talk about designs for that as

That's true, but it still requires the person writing the test to be familiar with both formats. Also anything more trivial than dumping a single local variable will probably run into even more issues. For example, The expression parsers each have their own unique quirks, and it might not always be easy to translate. Besides all the format compatibility issues, there's the more general

r287955 seems like it might be related. -- Sean Silva On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > This sounds buggy to me. What pass is doing this? > > -- Sean Silva > > On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> I've got some calls like: >>

Hi, When running my own lld generated library/executable I'm getting: LD_LIBRARY_PATH=. ./ConsoleApplication347 ./ConsoleApplication347: symbol lookup error: ./ConsoleApplication347: undefined symbol: (theres nothing after undefined symbol) How can I figure out what's I'm doing wrong? Full log: https://gist.github.com/carlokok/1dd510a16e1922271b520f1c00b14656 readelf -s for

What is the status of debuginfo-tests? Is it actively supported? How do you run it? It doesn't appear to be based on lit, any particular reason? Why is it its own repo instead of being part of llvm repo? I'd like improve this to support CodeView and PDB, such that it would only run on Windows and only if a suitable debugger was found (probably WinDbg). WinDbg supports a

When linking a project with lld, the android libc links to __executable_start which isn't defined when linking with lld (tried on x86), but is when linking with gnu ld it seems. I tried: .globl __executable_start __executable_start = __ehdr_start as a workaround but seems to be ignored. Anyone know a better workaround? Thanks, -- Carlo Kok RemObjects Software

As executable tests, they fail spectacularly in a cross-build environment. And you need some sort of debugger with GDB-like commands and output (or have some front end to your debugger that imitates that) in order to run them. I think they would need to stay in a separate project because of those requirements. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David

On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Carlo Kok <ck at remobjects.com> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > >> > >> If you pass --reproduce

Android libc casts its address to the elf header type. So I think start of text? Rafael Avila de Espindola <rafael.espindola at gmail.com> schreef op 30 mei 2017 20:51:19 CEST: >It is missing from lld. > >Do you know what it should point to? The first executable PT_LOAD? > >Thanks, >Rafael > >Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> writes: >

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the

I've got some calls like: musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod to void (i32, i8*)*)(i32 %0, i8* %1) ret void Into something like: %8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null) ret void I realize I'm losing a parameter there, but this is an interface jump trick I use and relies on the end code being a 'jmp' (x86). I realize i can probably

Thanks! Unfortunately this doesn't seem to cause it, because when I fix it to match the other files (and pretty much how clang emits it:) !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression()) !1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName: "f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID", scope: !2, file: !3, type: !622, isLocal:

Brief answer, but can go into detail later: If this is the right idea, lets do it for dwarf too & generalize the support to work for both. It's certainly something we've considered, to save all the complexity of representing essentially static data in an intermediate form. That said, given some of the stuff we have for lto, for example (deallocating/merging types etc) I'm not

On 2017-04-26 19:56, Eric Christopher wrote: > That's really weird. I'm quite surprised that the entry block was moved > so much later in the function but haven't had a chance to look more at > it. Probably want to take a look and find out where that's happening and > why. From irc, thegameg helped me find the -enable-shrink-wrap=false, which "fixes" this,

I have @_rtti_a_a = linkonce_odr constant in two files that end up as coff object files. Shoudln't the linkonce_odr prevent duplicate symbol: __rtti_a_a \consoleapplication149.o and __rtti_a_a island.lib(island.o) from happening in LLD? If not what alternative can I use? THis is used for template like generics, so having duplicate functions and globals is going to happen a lot) (Side

Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007