[lldb-dev] EuroLLVM'20 cancellation notice

The 2020 EuroLLVM Developers’ Meeting is cancelled because of COVID-19. We are sorry to announce that the 2020 EuroLLVM Developers’ Meeting is cancelled due to the COVID-19 outbreak. This was not a decision we took lightly. Here are the reasons we feel it is best to cancel EuroLLVM 2020. 1.

[lldb-dev] [GSoC20] Implement the missing tab completions for LLDB's command line

Hello Raphael, I am a final year BE undergraduate student at Samrat Ashok Technological Institute India. I would like to work on "Implementing the missing tab completions for LLDB's command line" for the GSoC program. I think tab completion is one of the essential facilities for the beginner user

Re: [lldb-dev] LLDB C++ API causes SIGSEGV

ed in processes and ensure minimal impact from just linking against the library. It is ok to call SBDebugger::Initialize() more than once, as the initialize will only happen once. Greg > On Mar 8, 2020, at 1:53 PM, Rui Liu via lldb-dev > wrote: > > Hi LLDB devs, > > I'

Re: [lldb-dev] LLDB C++ API causes SIGSEGV

Hi Rui, you need to call SBDebugger::Terminate() before your program exits. On 03/08/20 01:54 PM, Rui Liu via lldb-dev wrote: > > > Hi LLDB devs, > > I'm trying to build a debugger integration that uses LLDB C++ API. Due to > lack of documentation, I'm basical

[lldb-dev] LLDB C++ API causes SIGSEGV

Hi LLDB devs, I'm trying to build a debugger integration that uses LLDB C++ API. Due to lack of documentation, I'm basically using the examples in the python API as a guidance. I had following code, which basically contains one line creating a SBDebugger, but it generates a SIGSEGV fault.. #

Re: [lldb-dev] [llvm-dev] [10.0.0 Release] Release Candidate 3 is here

On Thu, Mar 5, 2020 at 4:20 PM Rainer Orth wrote: > > Hi Hans, > > > It took a bit longer than planned, but Release Candidate 3 is now > > here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at > > 3a843031a5 and contains 95 commits since the previous release > > candidate. > > > > If

Re: [lldb-dev] I wanna work on the open project "Add support for batch-testing to the LLDB testsuite."

Glad to hear from you. I am: jing...@apple.com Jim > On Mar 3, 2020, at 10:11 AM, SREENIVASA SUMADITHYA - IIITK via lldb-dev > wrote: > > I wanna work on the open project "Add support for batch-testing to the LLDB > testsuite." for google summer of code > Ca

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

:10 AM, Jim Ingham via lldb-dev > wrote: > > BTW, I think the better way to handle this in lldb is not to move the PC past > the trap when you stop, but that when CONTINUING past a trap that we don't > recognize, we always make sure we start past the trap. That way it w

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

BTW, I think the better way to handle this in lldb is not to move the PC past the trap when you stop, but that when CONTINUING past a trap that we don't recognize, we always make sure we start past the trap. That way it won't look weird when people compare crash logs coming from hitting a trap

Re: [lldb-dev] [llvm-dev] [10.0.0 Release] Release Candidate 3 is here

Thanks! Added. On Thu, Mar 5, 2020 at 3:15 PM Brian Cain wrote: > > Uploaded Ubuntu 18.04 binaries: > 7ebc00479d05772e56c34c1b0f40295af2dd4a6b165d9107946ff2cdb7c219ac > clang+llvm-10.0.0-rc3-x86_64-linux-gnu-ubuntu-18.04.tar.xz > > On Wed, Mar 4, 2020 at 7:49 AM Hans Wennborg via llvm-dev > w

Re: [lldb-dev] [llvm-dev] [10.0.0 Release] Release Candidate 3 is here

Uploaded Ubuntu 18.04 binaries: 7ebc00479d05772e56c34c1b0f40295af2dd4a6b165d9107946ff2cdb7c219ac clang+llvm-10.0.0-rc3-x86_64-linux-gnu-ubuntu-18.04.tar.xz On Wed, Mar 4, 2020 at 7:49 AM Hans Wennborg via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hello everyone, > > It took a bit longer than

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

On Wed, 2020-03-04 at 14:49 +0100, Hans Wennborg via Release-testers wrote: > Hello everyone, > > It took a bit longer than planned, but Release Candidate 3 is now > here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at > 3a843031a5 and contains 95 commits since the previous release >

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

On Wed, Mar 4, 2020 at 2:49 PM Hans Wennborg wrote: > > Hello everyone, > > It took a bit longer than planned, but Release Candidate 3 is now > here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at > 3a843031a5 and contains 95 commits since the previous release > candidate. > > If no

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

On Wed, Mar 4, 2020 at 2:49 PM Hans Wennborg wrote: > > Hello everyone, > > It took a bit longer than planned, but Release Candidate 3 is now > here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at > 3a843031a5 and contains 95 commits since the previous release > candidate. > > If no

[lldb-dev] [Bug 45112] New: Tests import "lldb.macosx.heap" incorrectly

https://bugs.llvm.org/show_bug.cgi?id=45112 Bug ID: 45112 Summary: Tests import "lldb.macosx.heap" incorrectly Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal

[lldb-dev] [Bug 44432] TestSourceManager failure on Windows (unable to set breakpoint by absolute path)

https://bugs.llvm.org/show_bug.cgi?id=44432 Tatyana Krasnukha changed: What|Removed |Added Fixed By Commit(s)||a31130f6fcf27518b31a8ac1f59

[lldb-dev] [Bug 44430] TestSettings failures on Windows (array-of-strings vs arguments)

https://bugs.llvm.org/show_bug.cgi?id=44430 Tatyana Krasnukha changed: What|Removed |Added Resolution|--- |FIXED CC|

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: > As you have seen, different machine architectures do different things after > hitting a trap. On x86_64, the trap instruction is executed, and then you > stop, so the PC is left after the stop. On arm64, when execution halts the > pc is sti

Re: [lldb-dev] Continuing from dbgtrap on different targets

ute, you just need to move the pc past the trap by hand (with the "thread jump" command) before continuing. That has always been safe on arm64 so far as I can tell. Jim > On Mar 4, 2020, at 12:16 PM, Joseph Tremoulet via lldb-dev > wrote: > > Hi, > > I’m notici

[lldb-dev] Continuing from dbgtrap on different targets

Hi, I'm noticing an unexpected difference between targets when I hit a dbgtrap in the debugger. Consider this simple llvm function: define void @do_break() { entry: call void @llvm.debugtrap() ret void } If I compile that with llc and use lldb to launch a program that calls it, on x

[lldb-dev] [10.0.0 Release] Release Candidate 3 is here

Hello everyone, It took a bit longer than planned, but Release Candidate 3 is now here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at 3a843031a5 and contains 95 commits since the previous release candidate. If no new problems arise, this is what the final release will look like. S

[lldb-dev] I wanna work on the open project "Add support for batch-testing to the LLDB testsuite."

I wanna work on the open project "Add support for batch-testing to the LLDB testsuite." for google summer of code Can I get more details on that? Can I get a contact for the confirmed mentor, Jim Ingham? ___ lldb-dev mailing list lldb-dev@lists.llvm.org

[lldb-dev] Proof of Concept for Live Reverse Debugging in LLDB

Hi everyone, I am currently finishing my master’s thesis and would like to show you what I have been working on for the past 7 months: https://github.com/vangelists/llvm-project/wiki/Reverse-Debugging The project is a proof of

Re: [lldb-dev] What are the 'rules' to play nice with lldb-9?

Thanks this has been very helpful On Mon, Mar 2, 2020 at 4:02 PM Adrian Prantl wrote: > > > > On Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I'm thoroughly confused so I may say incorrect thing. I don

Re: [lldb-dev] Is bitcast breaking lldb a bug?

it is LLDB loosing the variable and not clang? Does > clang produce a location for the variable when you look at the dwarfdump > output? > > -- adrian > > On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > This feels like

Re: [lldb-dev] Is bitcast breaking lldb a bug?

variable when you look at the dwarfdump > output? > > -- adrian > > On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > This feels like a bug to me. Yesterday I was asking what the rules were > because it felt like thi

Re: [lldb-dev] LLDB Website is not being updated

mit hook or nightly cron. >> > >> > -Tanya >> > >> >> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere >> wrote: >> >> >> >> I see a bunch of eros here: >> >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thre

Re: [lldb-dev] LLDB Website is not being updated

t; > > >> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere >> <mailto:jo...@devlieghere.com>> wrote: > >> > >> I see a bunch of eros here: > >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html > >> <http://lists.

Re: [lldb-dev] LLDB Website is not being updated

t;> I see a bunch of eros here: > >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html > >> > >> Is this possibly related to the Github/monorepo transition? > >> > >> -- Jonas > >> > >> On Thu, Nov 21, 2019 at 10:52 AM Ad

Re: [lldb-dev] LLDB Website is not being updated

I see a bunch of eros here: >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html >> >> Is this possibly related to the Github/monorepo transition? >> >> -- Jonas >> >> On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev >> wrote

Re: [lldb-dev] Is bitcast breaking lldb a bug?

AM, Levo DeLellis via lldb-dev > wrote: > > This feels like a bug to me. Yesterday I was asking what the rules were > because it felt like things change and break randomly. Now I have a good > example. (link to my email yesterday > http://lists.llvm.org/pipermail/lldb-dev/2020

Re: [lldb-dev] What are the 'rules' to play nice with lldb-9?

> On Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev > wrote: > > I'm thoroughly confused so I may say incorrect thing. I don't expect any > replies to this entire post but bits would be helpful. I'll double check if > you need me to be specific si

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

Jeremy, Vedant, thank you both for your help! I think I have something working pretty well: https://reviews.llvm.org/D75338 I'd greatly appreciate code review here -- in the course of writing the patch I definitely encountered gaps in my knowledge about debug info. In particular, I wasn't able to

Re: [lldb-dev] LLDB_PYTHON_HOME

. The problem appears that somehow CMake >>>> ignored your specified PYTHON_HOME and decided to pick a different Python. >>>> I'm not sure why though, because I use a similar CMake invocation on >>>> Windows. >>>> >>>> > cmake ..\llvm-project\llvm -G Ninja -DCMAKE

Re: [lldb-dev] LLDB_PYTHON_HOME

YPE=RelWithDebInfo >>> -DLLVM_ENABLE_PROJECTS="llvm;clang;lldb;lld" -DLLVM_ENABLE_ASSERTIONS=OFF >>> -DLLVM_ENABLE_ZLIB=FALSE -DLLDB_ENABLE_PYTHON=TRUE >>> -DPYTHON_HOME="C:/Program Files/Python36/" >>> >>> According to FindPython3 ( >

Re: [lldb-dev] LLDB_PYTHON_HOME

LE_PROJECTS="llvm;clang;lldb;lld" -DLLVM_ENABLE_ASSERTIONS=OFF >> -DLLVM_ENABLE_ZLIB=FALSE -DLLDB_ENABLE_PYTHON=TRUE >> -DPYTHON_HOME="C:/Program Files/Python36/" >> >> According to FindPython3 ( >> https://cmake.org/cmake/help/v3.12/module/FindPyth

Re: [lldb-dev] LLDB_PYTHON_HOME

, you can set > Python3_ROOT_DIR as a hint. Can you give that a try? If that works we > should populate that variable from PYTHON_HOME in > FindPythonInterpAndLibs.cmake. > > Cheers, > Jonas > > On Thu, Feb 27, 2020 at 10:10 AM Adrian McCarthy via lldb-dev < > lldb-dev@l

Re: [lldb-dev] LLDB_PYTHON_HOME

make. Cheers, Jonas On Thu, Feb 27, 2020 at 10:10 AM Adrian McCarthy via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Is there documentation on how lldb\include\lldb\host\config.h is > generated? I'm again having the problem of the config trying to point to > the wrong Python

[lldb-dev] LLDB_PYTHON_HOME

Is there documentation on how lldb\include\lldb\host\config.h is generated? I'm again having the problem of the config trying to point to the wrong Python installation. When I run cmake, I explicitly point PYTHON_HOME to C:\Python36 like this: cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN

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

> On Feb 26, 2020, at 3:29 PM, Brian Gesiak via lldb-dev > wrote: > > Vedant, Jeremy, > > Thanks a ton! I copied ASan's use of 'replaceDbgDeclare', think that worked! > > https://github.com/modocache/llvm-project/commit/afbc04e1dcba has some > extr

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

Vedant, Jeremy, Thanks a ton! I copied ASan's use of 'replaceDbgDeclare', think that worked! https://github.com/modocache/llvm-project/commit/afbc04e1dcba has some extremely quick and dirty changes I made (with no tests!), and a link to a Gist with the LLVM IR and DWARF produced, https://gist.git

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

Vedant, thank you! I had meant to ask if any of this reminded you all of something else that I could emulate. I'll look into uses of 'replaceDbgDeclare' in SafeStack/ASan. - Brian On Wed, Feb 26, 2020 at 5:08 PM Vedant Kumar wrote: > > I haven't fully parsed this thread (sorry!), but I wanted to

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

I haven't fully parsed this thread (sorry!), but I wanted to briefly mention that the SafeStack & ASan passes both do something similar (I think): move local variables backed by allocas onto a separate stack. These passes use replaceDbgDeclare to rewrite dbg.declares s.t. they point into the new

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

Awesome, thanks Jeremy. On Wed, Feb 26, 2020 at 11:02 AM Jeremy Morse wrote: > > Hi Brian, > > On Tue, Feb 25, 2020 at 7:43 PM Brian Gesiak wrote: > > In other words, the value of %i is stored on the frame object, on the > > heap, at an offset of 7 into the frame. I'm beginning to think a > > fu

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

Hi Brian, On Tue, Feb 25, 2020 at 7:43 PM Brian Gesiak wrote: > In other words, the value of %i is stored on the frame object, on the > heap, at an offset of 7 into the frame. I'm beginning to think a > fundamental fix for this issue would be to stop replacing > llvm.dbg.declare with llvm.dbg.val

[lldb-dev] [10.0.0 Release] We're behind schedule

Hello everyone, Today was the scheduled day for the final release tag, but the release is not ready yet. There are still a bunch of open blockers at https://llvm.org/PR44555 Any help on these is very much appreciated. My ambition is to get most of these fixed by the end of the week, tag RC3, an

[lldb-dev] Is bitcast breaking lldb a bug?

This feels like a bug to me. Yesterday I was asking what the rules were because it felt like things change and break randomly. Now I have a good example. (link to my email yesterday http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html) Take this example source file int main() {

[lldb-dev] What are the 'rules' to play nice with lldb-9?

I'm thoroughly confused so I may say incorrect thing. I don't expect any replies to this entire post but bits would be helpful. I'll double check if you need me to be specific since it's likely I remember or ran something wrong. For my language I output llvm-ir directly so I may generate llvm-ir th

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

Thanks all, especially Jeremy, for your help. > On Thu, Feb 6, 2020 at 11:04 AM Jeremy Morse > wrote: >> Everything in the IR appears correct to my eyes, although I know next >> to nothing about coroutines and might have missed something. Yes, good point. I think a better explanation of the cor

[lldb-dev] [Bug 45011] New: lldb can swallow some of the output when doing `p SM.dump(SourceLoc)`, or similar

https://bugs.llvm.org/show_bug.cgi?id=45011 Bug ID: 45011 Summary: lldb can swallow some of the output when doing `p SM.dump(SourceLoc)`, or similar Product: lldb Version: unspecified Hardware: PC OS: All

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

On 21/02/2020 23:32, Ted Woodward via lldb-dev wrote: > Looking into differences, I’m using swig 3.0.12 and the bot is using > swig 3.0.2. I’m building with 3.0.2 on my machine right now, but it will > take a while to finish! I think this could very likely be the cause. We use a

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

odward via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: I first noticed this issue when running print(lldb.SBHostOS.GetLLDBPythonPath()) in the script interpreter. It worked as expected on Linux and with an LLDB that I built on my machine, but when I ran it in an LLDB that our buildb

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

achines 64-bit? Are you launching Python from a 32- or 64-bit process? Is it the same on both machines? On Fri, Feb 21, 2020 at 1:02 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I first noticed this issue when running > print(lldb.SBHostOS.GetLLDBPythonPath()) in

[lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

I first noticed this issue when running print(lldb.SBHostOS.GetLLDBPythonPath()) in the script interpreter. It worked as expected on Linux and with an LLDB that I built on my machine, but when I ran it in an LLDB that our buildbots built, I got the wrong value - /lib/site-packages/lib/site-pack

[lldb-dev] [10.0.0 Release] Please help writing release notes!

Hello everyone, We're getting closer to the final release, and as usual I'd like to ask you all to help writing release notes. When the release happens, the first thing people tend to look at are the release notes, so they're a great opportunity to highlight the work that's been done over the pas

[lldb-dev] EuroLLVM'20: Diversity and Inclusion in Compilers and Tools workshop announcement

Hi All, It's my pleasure to announce the Diversity and Inclusion in Compilers and Tools workshop that will be held on the afternoon of April 5th, at the same venue as the EuroLLVM'20. This event features speakers and discussion aiming to increase diversity and inclusion within the LLVM community,

[lldb-dev] [Bug 26339] TestCPPAuto.py fails on Windows

https://bugs.llvm.org/show_bug.cgi?id=26339 Raphael Isemann changed: What|Removed |Added Resolution|--- |FIXED CC|

[lldb-dev] [Bug 44702] Backport f55ab6f90b7317a6bb85303a6102702bdae1199e to 10.0

https://bugs.llvm.org/show_bug.cgi?id=44702 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

On Mon, Feb 17, 2020 at 6:31 PM Michał Górny wrote: > > On Thu, 2020-02-13 at 23:34 +0100, Hans Wennborg via Release-testers > wrote: > > Hello everyone, > > > > Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It > > includes 98 commits since the previous release candidate. > >

Re: [lldb-dev] queue-name parameter

t; It sounds like what is really going on is that the queue matching isn't > working as you expected, so when you actually DID set a queue name - using > the "-q" option, the breakpoint wasn't stopping, but when you didn't set a > queue name (with the bogus -Q o

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

On 13 Feb 2020, at 23:34, Hans Wennborg via Release-testers wrote: > > Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It > includes 98 commits since the previous release candidate. For this rc, I used three patches, which are attached. Main results on amd64-freebsd11: E

Re: [lldb-dev] [llvm-dev] Have the debugger show an away with a dynamic size?

I added the VLA support to clang and lldb about a year ago, so you'll need fairly recent version of both for it to work. -- adrian > On Feb 17, 2020, at 12:25 PM, Levo DeLellis wrote: > > It looks like I wasn't careful and mixed version. I compiled with clang-9 but > used lldb-6. Surprisingly

Re: [lldb-dev] [llvm-dev] Have the debugger show an away with a dynamic size?

It looks like I wasn't careful and mixed version. I compiled with clang-9 but used lldb-6. Surprisingly this was the only error I notice when mixing these version. I could swear I tried compiling with clang-6. I'd double check but it appears that installing lldb-9 removed lldb(-6) from my system Th

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

On Thu, 2020-02-13 at 23:34 +0100, Hans Wennborg via Release-testers wrote: > Hello everyone, > > Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It > includes 98 commits since the previous release candidate. > This time I've switched to python3.8, and I've noticed that libc+

Re: [lldb-dev] [llvm-dev] Have the debugger show an away with a dynamic size?

That is interesting. According to LLDB's test/lang/c/vla/* frame variable for a VLA is supposed to work. Frame variable is also supposed to hide the __vla_expr0 artificial helper variable. Is this an older LLDB from your system or an LLDB you built from source? If yes, would you mind filing a bu

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

Thanks! Added this and the other binaries I've gotten so far to the release page and github. On Sat, Feb 15, 2020 at 6:25 PM Brian Cain wrote: > > Uploaded ubuntu 18 binaries. > > $ cat clang+llvm-10.0.0-rc2-x86_64-linux-gnu-ubuntu-18.04.tar.xz.sha256 > 8ca2cd0e0ba2243c095134373b46ccad822192b0495

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

On Thu, Feb 13, 2020 at 11:34 PM Hans Wennborg wrote: > > Hello everyone, > > Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It > includes 98 commits since the previous release candidate. > > Source code and docs are available at > https://prereleases.llvm.org/10.0.0/#rc2 and

[lldb-dev] Code of Conduct Next Steps - Community feedback needed

LLVM Community, The LLVM Code of Conduct has been in draft mode for several years now. In order to finalize the Code of Conduct, there are 3 steps left to complete: Draft an Incident Response Guide. This guide is intended for someone who is considering reporting a potential code of conduct vio

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

Uploaded ubuntu 18 binaries. $ cat clang+llvm-10.0.0-rc2-x86_64-linux-gnu-ubuntu-18.04.tar.xz.sha256 8ca2cd0e0ba2243c095134373b46ccad822192b0495ce13eb0af33e12f9d17e1 clang+llvm-10.0.0-rc2-x86_64-linux-gnu-ubuntu-18.04.tar.xz On Thu, Feb 13, 2020 at 4:34 PM Hans Wennborg via Release-testers < rel

[lldb-dev] Reminder: don't forget to register to EuroLLVM'20 !

If you are already registered to EuroLLVM'20 --- or not interested in it --- you can delete this email now. The EuroLLVM'20 program is available at http://www.llvm.org/devmtg/2020-04/#program and registrations are still open at http://www.llvm.org/devmtg/2020-04/#register with the early bird rate

[lldb-dev] [10.0.0 Release] Release Candidate 2 is here

Hello everyone, Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It includes 98 commits since the previous release candidate. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc2 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc2

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

Apologies for the slow response here Jeremy. Your reply has been incredibly helpful so far, I just need to try adding 'llvm.dbg.addr' myself to confirm that works. Thank you! - Brian Gesiak On Thu, Feb 6, 2020 at 11:04 AM Jeremy Morse wrote: > Hi Brian, > > Thanks for working on coroutines, the

Re: [lldb-dev] Moving lldbsuite API tests

I didn't actually get around to this yesterday. Landed minutes ago as 99451b4453688a94c6014cac233d371ab4cc342d. I'll keep an eye out for failures, but poke me if I miss something :) On Mon, Feb 10, 2020 at 9:21 AM Jonas Devlieghere wrote: > I'm very excited about this. Thank you for taking the t

[lldb-dev] [Bug 44872] New: Assertion `addr_size == 4 || addr_size == 8' failed when evaluating reference to a static array inside noinline static function in program compiled with -O2

https://bugs.llvm.org/show_bug.cgi?id=44872 Bug ID: 44872 Summary: Assertion `addr_size == 4 || addr_size == 8' failed when evaluating reference to a static array inside noinline static function in program compiled with -O2

[lldb-dev] [Bug 44864] lldb -python-path (with lldb installed using apt-get install lldb-9) returns an incorrect path

https://bugs.llvm.org/show_bug.cgi?id=44864 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

On 01/30/2020 12:47 PM, David Major wrote: > Would it make sense to wait until 10.0.0 is released, in order to keep all > the blockers in one place? > Yes, I think this makes sense, let's postpone until then. -Tom > > > On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev > mailto:llvm

Re: [lldb-dev] Moving lldbsuite API tests

I'm very excited about this. Thank you for taking the time and effort to make this happen! On Mon, Feb 10, 2020 at 9:01 AM Jordan Rupprecht wrote: > > Later today I'm planning to land D71151, which moves > lldb/packages/Python/lldbsuite/test to lldb/test/API, and removes the > lldb/test/API/tes

[lldb-dev] Moving lldbsuite API tests

Later today I'm planning to land D71151, which moves lldb/packages/Python/lldbsuite/test to lldb/test/API, and removes the lldb/test/API/testcases symlink. This is a large move, so I expect it will cause conflict for many outstanding patches with lldb tests. However, it should hopefully make testin

[lldb-dev] [Bug 44864] New: lldb -python-path (with lldb installed using apt-get install lldb-9) returns an incorrect path

https://bugs.llvm.org/show_bug.cgi?id=44864 Bug ID: 44864 Summary: lldb -python-path (with lldb installed using apt-get install lldb-9) returns an incorrect path Product: lldb Version: unspecified Hardware: PC

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

the stack pointer. If your address is in one of these ranges, then >> it's a stack address. Otherwise, it's probably heap (though you can never be >> 100% sure of that). >> >> However, it's not fully clear to me what it is that you're trying to do

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

address. Otherwise, it's probably heap (though > you can never be 100% sure of that). > > However, it's not fully clear to me what it is that you're trying to do > here. Maybe if you explain the higher level problem that you're trying to > solve, we can come up w

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

're trying to do here. > Maybe if you explain the higher level problem that you're trying to solve, we > can come up with a better solution. > > pl > > On Thu, 6 Feb 2020 at 07:40, Vangelis Tsiatsianas via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: >

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

l problem that you're trying to solve, we can come up with a better solution. pl On Thu, 6 Feb 2020 at 07:40, Vangelis Tsiatsianas via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi everyone, > > I am looking for a way to tell whether a memory address belongs to the > he

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

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?

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"?

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

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

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

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

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

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

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}

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

On 4 Feb 2020, at 12:06, Dimitry Andric via Release-testers wrote: > > On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers > wrote: >> >> It took a bit longer than planned due to master being a somewhat >> unstable at the branch point, but Release Candidate 1 has now been >> tagged as

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

https://bugs.llvm.org/show_bug.cgi?id=44791 Bug ID: 44791 Summary: LLDB 10.x (and current master) fails to build with GCC 5.4 Product: lldb Version: 10.0 Hardware: PC OS: All Status: NEW

[lldb-dev] [Bug 44774] New: basic_entry_values_x86_64 failing due to compiler changes

https://bugs.llvm.org/show_bug.cgi?id=44774 Bug ID: 44774 Summary: basic_entry_values_x86_64 failing due to compiler changes Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW

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

On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers wrote: > > It took a bit longer than planned due to master being a somewhat > unstable at the branch point, but Release Candidate 1 has now been > tagged as llvmorg-10.0.0-rc1. I tried building rc1 for 32-bit FreeBSD, but ran into a co

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

On 3 Feb 2020, at 10:57, Hans Wennborg wrote: > > On Fri, Jan 31, 2020 at 9:37 PM Dimitry Andric wrote: ... >> Unfortunately the test-suite did not build at all, as all the Bitcode >> compilations failed with segfaults, similar to the following run under >> gdb: >> >> Starting program: >> /hom

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

On Mon, Feb 3, 2020, 09:00 Michael Kruse wrote: > Am Do., 30. Jan. 2020 um 13:29 Uhr schrieb Jacob Lifshay via cfe-dev > : > > > > On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> > >> Hi, > >> > >> I want to restart this discussion. There seemed to

[lldb-dev] [Bug 44760] New: stop-hook doesn't work when user make ctrl-c interrupt

https://bugs.llvm.org/show_bug.cgi?id=44760 Bug ID: 44760 Summary: stop-hook doesn't work when user make ctrl-c interrupt Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: e

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

I'm happy to test things out, as long as it's not too much of a time sink (I have a lot on my plate at the moment, so something that takes more than the odd few minutes here and there may not be feasible). On Sat, 1 Feb 2020 at 02:10, Fangrui Song wrote: > On 2020-01-31, Tom Stellard via llvm-de

<    8   9   10   11   12   13   14   15   16   17   >