similar to: Temporary disable ASan's allocator check

> On Sep 6, 2017, at 9:14 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Sep 6, 2017 at 8:43 AM, Jonas Devlieghere via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi all, > > Is it possible to change the value of ASan's allocator_may_return_null at runtime or somehow disable this check

On Tue, Feb 12, 2019 at 11:05 AM Jonas Devlieghere via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Feb 12, 2019 at 10:54 AM Kostya Serebryany <kcc at google.com> wrote: > >> >> >> On Tue, Feb 12, 2019 at 10:45 AM Jonas Devlieghere <jonas at devlieghere.com> >> wrote: >> >>> Hi Kostya, >>> >>> I remember

On Tue, Feb 12, 2019 at 10:45 AM Jonas Devlieghere <jonas at devlieghere.com> wrote: > Hi Kostya, > > I remember seeing this in the past. IIRC it was sufficient to install > recommonmark with `pip install recommonmark`. > installing this on my machine won't help the bots that build the docs, right? > > Cheers, > Jonas > > On Tue, Feb 12, 2019 at 10:17 AM

On Mon, Dec 8, 2014 at 2:00 AM, Alexander Potapenko <glider at google.com> wrote: > Hope you're assuming there's always a single copy of common_flags in > the process. > This isn't the case for e.g. ASan+UBSan on Mac, but that's a broken setup. > > What if we let the tools protect specific flags (by adding a bool to > each flag) once they set their values

On 16/12/2019 23:47, David Blaikie via llvm-dev wrote: > > > On Mon, Dec 16, 2019 at 2:40 PM Jonas Devlieghere <jonas at devlieghere.com > <mailto:jonas at devlieghere.com>> wrote: > > Hey James, > > This sounds really interesting. A few things that come to mind: > >  - I'm curious what kind of errors you'd be okay with in dump

On Tue, Jan 7, 2020 at 5:35 PM Jonas Devlieghere <jonas at devlieghere.com> wrote: > On Tue, Jan 7, 2020 at 5:16 PM Bill Wendling via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > > > On Tue, Jan 7, 2020 at 4:59 PM Doerfert, Johannes <jdoerfert at anl.gov> > wrote: > >> > >> Hi Bill, > >> > >> On 01/07, Bill Wendling

Hey James, This sounds really interesting. A few things that come to mind: - I'm curious what kind of errors you'd be okay with in dump mode but not in consumer mode. From LLDB's perspective, we probably want to extract as much information as possible from a malformed line table, as long as we don't end up lying of course. - I need to take another look at the code, but

Hi Mats, When the struct is packed, explicit byte array is introduced to pad the struct. (I saw this happened in clang 3.9.) I want to check if a byte or byte array in an LLVM struct is introduce for explicit padding or not. I don't need to worry about this problem in case the newest clang do not introduce byte array anymore. Thanks Hongbin On Thu, May 18, 2017 at 1:03 AM, mats petersson

I'm not sure a decision was already made as such. I think it's more that there was a flurry of conversation last time with lots of conflicting opinions, and then the conversation just fizzled out. FWIW, I like Phabricator but I'm willing to try GitHub. Overall I think we should take the same approach that eventually led to Phabricator being widely adopted: We should allow GitHub

TL;DR: If I'm trying to define new assembler directive syntax to support DWARF v5, it seems like a good idea for all the various assemblers out there in the world to support the same syntax. How would I go about negotiating that syntax with other assembler providers? Is GNU as the only really relevant one? Long version: DWARF v5 introduces a couple of new features in the .debug_line section

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > * It supports Linux, macOS and Windows (and presumably other platforms). > * It

Hi, I am wondering how I can tell whether a field of a struct is introduced by padding or not. For example, if I have a struct: struct foo1 { char *p; /* 8 bytes */ char c; /* 1 byte long x; /* 8 bytes */ }; clang may generate: struct foo1 { char *p; /* 8 bytes */ char c; /* 1 byte char pad[7]; /* 7 bytes */ long x; /* 8 bytes */ }; Is

On Fri, Jan 31, 2020 at 6:09 AM Robinson, Paul via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of John > Marshall > > via cfe-dev > > Sent: Friday, January 31, 2020 7:04 AM > > To: Jonas Devlieghere via cfe-dev <cfe-dev at lists.llvm.org> >

Hi, I would like to improve the debugging experience for ASan. The idea is to have a couple of useful commands in LLDB (probably implemented as Python scripts) that could help the user when they are debugging an ASan-enabled binary. We already have some debugging API (asan_interface.h): // Print the description of addr (useful when debugging in gdb). void __asan_describe_address(void

FWIW I'm completely on board with everything Adrian has said in this thread :) -eric On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > As mentioned by Adrian in the comment you linked, I too

Hi, docs seem to be broken. e.g. r353563 adds docs for callbr, but https://llvm.org/docs/LangRef.html doesn't have it. trying to build the docs manually on my box: ninja docs-llvm-html FAILED: docs/CMakeFiles/docs-llvm-html cd /usr/local/google/home/kcc/llvm-build/docs && /usr/bin/sphinx-build -b html -d /usr/local/google/home/kcc/llvm-build/docs/_doctrees-llvm-html -q -W

On Thu, Nov 14, 2019 at 1:53 PM Robinson, Paul <paul.robinson at sony.com> wrote: > My reading of the DWARF issue is that it was fairly specifically designed > to handle the case of a function taking parameters by pointer/reference, > which is then inlined, and the caller is passing local objects rather than > other pointers/references. So: > > > > void

Hi Tim, Thank you for clarifying what the error actually means! I did read something about the BLX instruction but since I'm compiling strictly for thumb, it didn't make much sense to me. Adding -mdisable-tail-calls as a cc1 command indeed allowed me to link the generated binary. After looking some more at the ld64 source code, I came across the following comment: // The tail-call

Hello, Thanks for prompt reply. Motivation, In case of debugging of bi-endian dwarf and value known at runtime some of the raw values needs to be byte swapped to change the endianity. We have a llvm based compiler which generates such dwarf, TAG_variable marked as big endian and debugging on little endian host using lldb. The listed operator on dwarf issues does that, one operator instead of

On Fri, Nov 15, 2019 at 8:07 AM Robinson, Paul <paul.robinson at sony.com> wrote: > | Any ideas why it wouldn't be more general to handle cases where the > variable isn't named? > > > > Couldn’t there be a DIE (flagged as artificial) to describe the > return-value temp? > There could be - though there are very few (the array bound example Adrian gave is the