similar to: Debug Locations for Optimized Code

>> I don't know what the right, if any, solution to this is - but I >> thought I should bring it up in case you or anyone else wanted to >> puzzle it over & see if the competing needs/desires might need to be >> considered. > One thing that I recall being discussed was changing the way that we > set the is_stmt flag in the DWARF line-table information. As I

----- Original Message ----- > From: "Andrea Di Biagio" <andrea.dibiagio at gmail.com> > To: "Paul Robinson" <paul.robinson at sony.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "David Blaikie" > <dblaikie at gmail.com>, llvm-dev at lists.llvm.org > Sent: Thursday, December 15, 2016 9:05:00 AM > Subject: Re:

On Wed, Dec 7, 2016 at 3:39 PM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > >> I don't know what the right, if any, solution to this is - but I > >> thought I should bring it up in case you or anyone else wanted to > >> puzzle it over & see if the competing needs/desires might need to be > >> considered. > > One thing

On Wed, Dec 7, 2016 at 10:20 AM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Paul Robinson" <paul.robinson at sony.com> > > To: "Hal Finkel" <hfinkel at anl.gov>, "David Blaikie" <dblaikie at gmail.com> > > Cc: llvm-dev at lists.llvm.org > > Sent: Wednesday, December 7, 2016

my 2c. the sanitizers rely on debug info to produce human-readable error messages, and I agree with Reid that it's unwise to have a parallel way of encoding the source locations. Well, we have something like this in the clang coverage already... Right? (I never particularly liked this design decision). But since the debug info is known to be unreliable it kind of made sense. Grrr. And since

I don't see how ASan and debuggers are different. It feels like both need reasonably accurate source location attribution for any instruction. ASan just happens to care more about loads and stores than interactive stepping debuggers. Actually they are pretty different in their requirements. ASan cares about *accurate* source location info for *specific* instructions, the ones that do

There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch. --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 4:08 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Libfuzzer depending on uninitialized debug info On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <paul.robinson at

Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives. They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue. Regarding "how

On Fri, Dec 2, 2016 at 5:42 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > I've determined that the "pesky" .loc is indeed because of the .cfi > directive that comes immediately after it. Some of the CFI instructions > have source locations, some don't. But, emitting a source location for a > CFI instruction is inappropriate. It's easy enough to

(2) cause CFI instructions not to emit any .loc directives; done in r289256, plus r289288 (3) file a bug to have someone audit LoopVectorizer.cpp to see whether it is using SetCurrentDebugLocation in the right places; haven't done that part yet (4) reapply my "line 0" patch, which will be the 3rd attempt. r289468 Please ping me when you do (4). Also, will there be a flag to disable

Isn't this a typcial situation when the is_stmt field in the DWARF line table should be used? If we set is_stmt=0 for the instruction loading the constant, then a debugger can choose not to stop on that instruction when doing "step" on source level. That way we can keep the original source location for a ConstantSDNode, but also telling the debugger that this isn't a recommended

Hello llvmdev, I would like to propose and discuss yet another dynamic tool, which we call MemorySanitizer (msan). The main goal of the tool is to detect uses of uninitialized memory (the major feature of Valgrind/Memcheck not covered by AddressSanitizer). It will also find use-after-destruction-but-before-free in C++. The algorithm of the tool is similar to that of Memcheck (

On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote: > > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger < > joerg at britannica.bec.de > > > wrote: > > > > > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote: > > > >

On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote: > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger < > joerg at britannica.bec.de > > > wrote: > > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > > >

I've just sent a code review request to llvm-commits. --kcc On Mon, Jun 18, 2012 at 2:39 PM, Kostya Serebryany <kcc at google.com> wrote: > Hello llvmdev, > > I would like to propose and discuss yet another dynamic tool, which we > call MemorySanitizer (msan). > The main goal of the tool is to detect uses of uninitialized memory (the > major feature of

On Mon, Jun 18, 2012 at 06:44:57PM +0400, Kostya Serebryany wrote: > On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <joerg at britannica.bec.de > > wrote: > > > On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote: > > > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger < > > joerg at britannica.bec.de > > > > wrote: > >

On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote: > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <joerg at britannica.bec.de > > wrote: > > > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote: > > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger < > > joerg at britannica.bec.de > > > > wrote: > >

Hi again, MemorySanitizer (msan) is now mature enough to bootstrap LLVM and run it w/o any additional tools. Msan has already found one bug in LLVM itself: http://llvm.org/bugs/show_bug.cgi?id=13929 Would anyone be willing to do a codereview (it was sent to llvm-commits: http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/123253) Thanks, --kcc On Tue, Jun 19, 2012 at 11:34 AM, Kostya

On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > Another difference from Memcheck is that we propose to use 8 shadow bits > > per byte of application memory and use a > > direct shadow mapping (for 64-bit linux that is just clearing 46-th bit > of >

Hi Kostya, >On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch >> wrote: > >> Dear LLVM developers, >> >> We've applied the feedback we received on Phabricator on the SafeStack >> patches, >> > >Did you investigate the possibility of moving the transformation from >codegen to the LLVM level, i.e. the same level