Re: [lldb-dev] How to tell if an address belongs to the heap?

2020-02-06 Thread Pavel Labath via lldb-dev
In general, getting this kind of information is pretty hard, so lldb does not offer you an out-of-the-box solution for it, but it does give you tools which you can use to approximate that. If I wanted to do something like this, the first thing I'd try to do is run "image lookup -a 0xaddr". If this

Re: [lldb-dev] [llvm-dev] Why is lldb telling me "variable not available"?

2020-02-06 Thread Jeremy Morse via lldb-dev
Hi Brian, Thanks for working on coroutines, the debugging experience, and in particular thanks for the comprehensive write-up!, On Thu, Feb 6, 2020 at 1:19 PM Brian Gesiak via llvm-dev wrote: > Specifically, I’m trying to improve lldb’s behavior when showing > variables in the current stack fram

[lldb-dev] How to tell if an address belongs to the heap?

2020-02-06 Thread Vangelis Tsiatsianas via lldb-dev
Hi everyone, I am looking for a way to tell whether a memory address belongs to the heap or not. In other words, I would like to make sure that the address does not reside within any stack frame (even if the stack of the thread has been allocated in the heap) and that it’s not a global variabl

[lldb-dev] Why is lldb telling me "variable not available"?

2020-02-06 Thread Brian Gesiak via lldb-dev
Hi all, I’m working on improving the debugging experience for C++20 coroutines when compiled with LLVM/Clang, and I could use some help from someone who understands debug information and DWARF (knowledge of coroutines isn't necessary, I don't think). Specifically, I’m trying to improve lldb’s beha

Re: [lldb-dev] [cfe-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-06 Thread Hans Wennborg via lldb-dev
On Thu, Feb 6, 2020 at 1:14 PM Yvan Roux wrote: > > Hi Hans, > > On Thu, 6 Feb 2020 at 12:40, Hans Wennborg wrote: > > > > On Thu, Feb 6, 2020 at 11:16 AM Yvan Roux wrote: > > > > > > Hi, > > > > > > here are the results for ARM targets: > > > > > > * 32-bit has the same issue reported in PR4476

Re: [lldb-dev] [cfe-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-06 Thread Hans Wennborg via lldb-dev
On Thu, Feb 6, 2020 at 11:16 AM Yvan Roux wrote: > > Hi, > > here are the results for ARM targets: > > * 32-bit has the same issue reported in PR44767 > > * same issue with quick-append.text for AArch64 check-all results are: > Testing Time: 4520.30s > > Failing Tests (1): >

Re: [lldb-dev] [Release-testers] [cfe-dev] [10.0.0 Release] Release Candidate 1 is here

2020-02-06 Thread Dimitry Andric via lldb-dev
On 6 Feb 2020, at 11:16, Yvan Roux via Release-testers wrote: ... > And a bunch of errors in the testsuite: > > FAILED: > Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o > /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/test-suite-

[lldb-dev] [Bug 44791] LLDB 10.x (and current master) fails to build with GCC 5.4

2020-02-06 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=44791 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-06 Thread Hans Wennborg via lldb-dev
On Wed, Feb 5, 2020 at 9:30 PM Anil Mahmud wrote: > > The following error was found when running test-release.sh on Red Hat 7.4 > > > FAIL: LLVM :: tools/llvm-ar/quick-append.test (53100 of 59657) > TEST 'LLVM :: tools/llvm-ar/quick-append.test' FAILED >

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

2020-02-06 Thread Hans Wennborg via lldb-dev
On Wed, Feb 5, 2020 at 9:00 PM Anil Mahmud wrote: > > Hello, > > When running test-release.sh using GCC 5.4.0 we encountered this error : > > /home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp: > In function ‘llvm::StringLiteral > clang::clangd::{anonymous}