similar to: [LLVMdev] Adding line table debug information to LLVM on Windows

Hi Timur, There's also a pending patch adding CodeView support in Phab: http://llvm-reviews.chandlerc.com/D165 Does your patch provide just a subset of the CodeView debug info provided in the other patch? Looking at the patch, I think the approach the other patch took of abstracting the emission of debug information is a bit cleaner and it will probably make life easier when adding more

2013/11/14 Timur Iskhodzhanov <timurrrr at google.com>: > Hi David, Eric, LLVM devs, > > You've probably heard about AddressSanitizer (ASan) and other > sanitizers based on LLVM. One of the things that makes ASan > not as awesome on Windows as it is on Linux > is the symbolization of the stacks. > > Currently, ASan runtime on Windows uses >

I wrote some more lit tests for my patch and realized I was generating some redundant info. This is fixed now. Attached is a new version of the prototype patch with some more tests. 2013/11/15 João Matos <ripzonetriton at gmail.com>: > Hi Timur, > > There's also a pending patch adding CodeView support in Phab: > http://llvm-reviews.chandlerc.com/D165 I haven't looked at

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 we move on. As far as how to migrate the decision down we can have it both as an option to code gen maybe or, for now, make it dependent upon triple. The

>> > >> >> Probably the same structure that we've been going down via >> lib/DebugInfo/. A set of files than handle reading and parsing and >> both some binary files and some files produced by the backend. > > > Ooph, that's a big one. > Any more tips to prioritize diving into this codebase? > It mostly uses libObject to do the initial read

On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Eric, David, > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: >> Attached is a slightly updated patch. >> (it doesn't include D2222 yet). > > The new version of the patch stopped fitting into the llvmdev 100K limit, > so I've uploaded it to

2013/12/3 Eric Christopher <echristo at gmail.com> > >> > > >> > >> Probably the same structure that we've been going down via > >> lib/DebugInfo/. A set of files than handle reading and parsing and > >> both some binary files and some files produced by the backend. > > > > > > Ooph, that's a big one. > > Any

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

On Tue, Dec 3, 2013 at 11:04 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > > > > 2013/12/3 Eric Christopher <echristo at gmail.com> >> >> >> > >> >> >> >> Probably the same structure that we've been going down via >> >> lib/DebugInfo/. A set of files than handle reading and parsing and >> >>

2013/11/21 Eric Christopher <echristo at gmail.com> > On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com> > wrote: > > Eric, David, > > > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: > >> Attached is a slightly updated patch. > >> (it doesn't include D2222 yet). > > > > The new

Eric, David, 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: > Attached is a slightly updated patch. > (it doesn't include D2222 yet). The new version of the patch stopped fitting into the llvmdev 100K limit, so I've uploaded it to http://llvm-reviews.chandlerc.com/D2232 (you need to apply D2222 first if you'd like to give D2232 a try) > 2013/11/19 Eric

unsubscribe ----- Original Message ----- From: llvmdev-request at cs.uiuc.edu To: llvmdev at cs.uiuc.edu Sent: Tuesday, November 19, 2013 5:08:13 PM Subject: LLVMdev Digest, Vol 113, Issue 74 Send LLVMdev mailing list submissions to llvmdev at cs.uiuc.edu To subscribe or unsubscribe via the World Wide Web, visit http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev or, via email, send a message

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

I think this issue is that we were not using the INTERCEPTOR macros to define these functions. The following patch seems to work for me to get the build linking again, however, I cannot test -- when I run check-asan, I get: 2> lit.py: lit.common.cfg:59: fatal: Invalid llvm_tools_dir config attribute: 'E:/llvm/2013/$(Configuration)/bin' ~Aaron On Thu, Oct 23, 2014 at 1:20 PM, Aaron

http://llvm.org/bugs/show_bug.cgi?id=21241 ? 2014-10-23 10:18 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 1:15 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 1:13 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> Yes it is. >>> Are you doing a Debug or Release build?

compiler-rt libs must be built with /MT, so the MSVS build is doing the wrong thing here. 2014-10-23 12:52 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 3:42 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >>> On Thu, Oct 23, 2014 at 2:57

On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com>wrote: > Eric, David, > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: > > Attached is a slightly updated patch. > > (it doesn't include D2222 yet). > > The new version of the patch stopped fitting into the llvmdev 100K limit, > so I've uploaded it to

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >>>> On Thu, Oct

On Thu, Oct 23, 2014 at 1:13 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Yes it is. > Are you doing a Debug or Release build? > Using ninja? Release build, cmake + MSVC (not using ninja). Perhaps I have it configured stupidly; I have it as an out-of-tree folder, did: E:\llvm\crt_build>cmake -DLLVM_CONFIG_PATH=E:\llvm\2013\Debug\bin -G "Visual Studio 12"