similar to: [LLVMdev] Debug information under windows

Hello, Recently I found binaries produced with LLVM impossible to debug under Windows. This was probably related to the following bug: http://llvm.org/bugs/show_bug.cgi?id=13636 Asm generated from .ll files revealed that some offsets to debug information were incorrect: they were absolute instead of relative to their sections. Following patch seemed to have repaired the problem, so I'm

W dniu 2012-10-26 16:55, Daniel Kłobuszewski pisze: > Hello, > > Recently I found binaries produced with LLVM impossible to debug under > Windows. This was probably related to the following bug: > http://llvm.org/bugs/show_bug.cgi?id=13636 > > Asm generated from .ll files revealed that some offsets to debug > information were incorrect: they were absolute instead of

Can you add some tests? On 26 October 2012 10:55, Daniel Kłobuszewski <daniel.klobuszewski at ibs.org.pl> wrote: > Hello, > > Recently I found binaries produced with LLVM impossible to debug under > Windows. This was probably related to the following bug: > http://llvm.org/bugs/show_bug.cgi?id=13636 > > Asm generated from .ll files revealed that some offsets to debug

I'm trying to insert some DWARF debugging information into a LLVM IR module by manually parsing the DWARF debug DIEs. I'm doing it that way since I wrote my custom front-end for my language and the DWARF debugging information are provided me as a byte stream for the various DWARF sections. I took a look at the documentation and DwarfDebug class (

>Wasn't our (lld/ELF's) position on debug info size that we should focus on providing a great split-dwarf workflow and not try go too far out of our way to deduplicate >or otherwise reduce debug info size inside LLD? I recall there being some patches that made linking of large debug binaries like 1.5GB+ clang faster, but we decided to >reject those changes because split-dwarf was

On Sat, Dec 16, 2017 at 11:40 AM George Rimar <grimar at accesssoftek.com> wrote: > Or following workflow: > > Split dwarf is used to make linker to proccess less, like relocations, > right ? > Partly, though the main motivation as far as I know, was to have to provide fewer bytes to the linker at all. That's why something like Apple's scheme (leave the debug info in

Hi all, We had some problems in the past when generating debug information, for which I have started a documentation [1]. The recent change to DIBuilder made it more difficult to check for inconsistencies, since neither the original interface nor the current one are documented. This is creating a lot of problems when integrating our front-end to LLVM and we never quite got the debug information

?But could not we for example do split dwarf, but for example do dedup of types ? I do not mean right now, but in a theory ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 16 декабря 2017 г. 22:25 Кому: George Rimar Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola Тема:

2013/11/20 Reid Kleckner <rnk at google.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 version

Hello, I'm trying to use DWARF informations to debug JITed code, but lli crashes when it tries to run any code coming from llvm-gcc or CLANG with the -g and -emit-llvm -c arguments. The target machine is an AMD 64 X2 processor on linux ubuntu 9.04 in x86_64 mode. Lli is generated from the current version of the svn repository. The backtrace and full bt from gdb are enclosed with this

>Not quite sure what you mean by "on linker side" - but I guess you mean using linker features like comdats etc, rather than DWARF parsing/reassembly/etc. I mean that it probably not a good idea for external library. I feel it is much more convinent to do such proccessing in a linker. Linker do and knows much more about things like sections that are ICFed, eliminated, about COMDATs

Regarding flags, I was just thinking that maybe we should invent a new DISubprogramFlags type. DISubprogram already has a few bitfields for subprogram-specific things, Fortran will want 3 more, and there's no reason to fill up the generic DIFlags with more bits that are used in only one class. I agree that the array stuff needs to be designed with an eye to handling how other languages do

> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Hi, > > I'm trying to achieve the following: > > - I have a global variable BaseAddress that holds the base address of > a contiguous dynamically allocated memory block. > > - I have a number of logical variables of different types that are > mapped on certain address

LGTM. I think you can sent patch and let the ball rolling! I would like to review it. ;) 2018-03-28 10:41 GMT+08:00 Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org>: > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on

See "DwarfDebug problem with line section" thread on llvmdev. Bottom line, we may need a target specific patch for targets that do not follow dwarf standard (as per my reading) in this particular case. - Devang On Wed, Aug 25, 2010 at 5:49 AM, Renato Golin <rengolin at systemcall.org>wrote: > Hi, > > I'm trying to compile two files together with debug information

> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Adrian, > > Thanks for a quick reply! > > On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Hi, >>>

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 >

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

Sounds good to me. You can also see llvm.codeview.annotation which does a similar thing, but it is modeled as having internal, invisible side effects. These should stay separate, but it may provide a guide for implementation. On Tue, Mar 27, 2018 at 7:41 PM Hsiangkai Wang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello all, > > I would like to enhance LLVM debug info

Hi, I'm trying to achieve the following: - I have a global variable BaseAddress that holds the base address of a contiguous dynamically allocated memory block. - I have a number of logical variables of different types that are mapped on certain address ranges inside the memory block pointed to by BaseAddress. The offset and the size of each such logical variable inside the memory block are