Re: [lldb-dev] Mailman->Discourse Migration on February 1, 10am PST

2022-02-01 Thread Tanya Lattner via lldb-dev
As a reminder, this will be happening this morning. Thanks, Tanya > On Jan 29, 2022, at 8:29 AM, Tanya Lattner wrote: > > LLVM Community, > > As referenced in this blog post > , we are getting > close to the deadline for migration

Re: [lldb-dev] Mailman->Discourse Migration on February 1, 10am PST

2022-01-31 Thread Tanya Lattner via lldb-dev
Thank you Paul for pointing this out. I will get this information updated tonight. -Tanya > On Jan 29, 2022, at 9:58 AM, Paul Smith wrote: > > On Sat, 2022-01-29 at 08:29 -0800, Tanya Lattner via lldb-dev wrote: >> We will use the Discourse Migration website to communicate whe

Re: [lldb-dev] Accessing attached process environment variables with SBAPI

2022-01-31 Thread Jim Ingham via lldb-dev
that fetched the current process environment, however. Please file an enhancement request or propose a patch. Jim > On Jan 28, 2022, at 4:35 PM, Ivan Hernandez via lldb-dev > wrote: > > Hi all, > > I'm trying to read the value of an environment variable that a proce

Re: [lldb-dev] Mailman->Discourse Migration on February 1, 10am PST

2022-01-29 Thread Paul Smith via lldb-dev
On Sat, 2022-01-29 at 08:29 -0800, Tanya Lattner via lldb-dev wrote: > We will use the Discourse Migration website to communicate where we > are in the process. Just to point out that the "Setting up email interactions" section on this page could use some attention. For example

[lldb-dev] Mailman->Discourse Migration on February 1, 10am PST

2022-01-29 Thread Tanya Lattner via lldb-dev
LLVM Community, As referenced in this blog post , we are getting close to the deadline for migration for some Mailman lists to Discourse. If you are receiving this email from a LLVM Mailman list, then this list will be migrating to D

[lldb-dev] Accessing attached process environment variables with SBAPI

2022-01-28 Thread Ivan Hernandez via lldb-dev
Hi all, I'm trying to read the value of an environment variable that a process was launched with but to which lldb attached to after it launched. SBEnvironment looked interesting but I tried using ``` script print(lldb.debugger.GetSelectedTarget().GetEnvironment().Get("PRINT_ME") ``` and that prin

Re: [lldb-dev] Semantics of SBValue::CreateChildAtOffset

2022-01-28 Thread Greg Clayton via lldb-dev
> On Oct 22, 2021, at 6:12 AM, Pavel Labath via lldb-dev > wrote: > > Hello Jim, everyone, > > I recently got a question/bug report about python pretty printers (synthetic > child providers) that I couldn't answer. > > The actual script is of course more co

Re: [lldb-dev] Why can't I break on an address resulting in unresolved?

2022-01-28 Thread Greg Clayton via lldb-dev
loaded at a specific location, which means if you did a "br s -a 0x1000", this address could match every shared library since each shared library could have a "file address" values of 0x1000. > On Nov 17, 2021, at 4:23 AM, Pi Pony via lldb-dev > wrote: > > Hel

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

2022-01-28 Thread Greg Clayton via lldb-dev
> On Oct 28, 2021, at 6:33 AM, Pavel Labath via lldb-dev > wrote: > > Hello everyone, > > I'd like to propose a new plugin for better lldb+qemu integration. > > As you're probably aware qemu has an integrated gdb stub. Lldb is able > to communicate w

Re: [lldb-dev] No script in lldb of build

2022-01-28 Thread Greg Clayton via lldb-dev
I have had to add the following to my cmake command line: -DPython3_EXECUTABLE=/usr/bin/python3 > On Dec 5, 2021, at 12:02 PM, Pi Pony via lldb-dev > wrote: > > Hello, > > I build lldb for macOS and tried to get into script but I get this error > message: there

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2022-01-28 Thread Greg Clayton via lldb-dev
he targeted process. > On Nov 30, 2021, at 5:49 AM, Michał Górny via lldb-dev > wrote: > > Hi, > > I'm working on a FreeBSD-sponsored project aiming at improving LLDB's > support for debugging FreeBSD kernel to achieve feature parity with > KGDB. As a part

Re: [lldb-dev] Source-level stepping with emulated instructions

2022-01-28 Thread Greg Clayton via lldb-dev
nary has a "printf" symbol which is the trampoline to the actual "printf" function, the stepping logic will just continue through this code until it gets out of the address range. > On Jan 14, 2022, at 10:49 PM, Kjell Winblad via lldb-dev > wrote: > > Hi! &g

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-28 Thread Greg Clayton via lldb-dev
s like the uncaught exceptions for C++ (GDB has a way of vending info on these exceptions in certain cases too. > On Jan 13, 2022, at 9:09 AM, Jim Ingham via lldb-dev > wrote: > > You are really going to make a lldb_private::CompilerType, since that’s what > backs the Type & ult

Re: [lldb-dev] problems using EvaluateExpression in lldb, when it creates new object

2022-01-28 Thread Greg Clayton via lldb-dev
> On Jan 14, 2022, at 10:13 AM, fhjiwerfghr fhiewrgfheir via lldb-dev > wrote: > > I'm sorry in advance, if it's not a correct mailing list, there doesn't seem > to be lldb-usage mailing list. > > I'm writing a pretty-printer python script, whic

Re: [lldb-dev] Multiple platforms with the same name

2022-01-28 Thread Pavel Labath via lldb-dev
I'm sorry for the slow response. I had to attend to some other things first. It sounds like there's agreement to support multiple platform instances, so I'll try to move things in that direction. Further responses inline On 20/01/2022 01:19, Greg Clayton wrote: On Jan 19, 2022, at 4:28 AM,

Re: [lldb-dev] lldb-vscode plugin information for Windows/Arm platform

2022-01-21 Thread Ted Woodward via lldb-dev
The last 2 Hexagon release trains have shipped with vscode support on Linux and Windows. I worked with Greg to do what you want to do – make a vscode extension to allow it to use lldb-vscode as its debugger. I wrote a batch script that: * Removes the extension directory * Creates the ex

Re: [lldb-dev] lldb-vscode plugin information for Windows/Arm platform

2022-01-20 Thread Greg Clayton via lldb-dev
> On Jan 20, 2022, at 4:40 PM, Omair Javaid wrote: > > Hi Greg, > > I intend to understand requirements to set up the lldb-vscode tool for > Windows on Arm. I have been looking at your vscode readme from > https://github.com/llvm/llvm-project/blob/cfae2c65dbbe1a252958b4db2e32574e8e8dcec0/lld

[lldb-dev] lldb-vscode plugin information for Windows/Arm platform

2022-01-20 Thread Omair Javaid via lldb-dev
Hi Greg, I intend to understand requirements to set up the lldb-vscode tool for Windows on Arm. I have been looking at your vscode readme from https://github.com/llvm/llvm-project/blob/cfae2c65dbbe1a252958b4db2e32574e8e8dcec0/lldb/tools/lldb-vscode/README.md If I understood correctly Windows on A

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-20 Thread Greg Clayton via lldb-dev
Understood, we need to be able to log if "any" bits are set. > On Jan 20, 2022, at 2:18 PM, Jim Ingham wrote: > > > >> On Jan 20, 2022, at 11:26 AM, Pavel Labath wrote: >> >> On 20/01/2022 00:30, Greg Clayton wrote: >>> I also vote to remove and simplify. >> >> Sounds like it's settled the

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-20 Thread Jim Ingham via lldb-dev
> On Jan 20, 2022, at 11:26 AM, Pavel Labath wrote: > > On 20/01/2022 00:30, Greg Clayton wrote: >> I also vote to remove and simplify. > > Sounds like it's settled then. I'll fire up my sed scripts. > > On 20/01/2022 01:38, Greg Clayton wrote: >> On Jan 19, 2022, at 6:40 AM, Pavel Labath wr

Re: [lldb-dev] [Release-testers] LLVM 14.0.0 Release Schedule

2022-01-20 Thread Tom Stellard via lldb-dev
On 1/20/22 00:28, Michał Górny wrote: On Wed, 2022-01-19 at 21:23 -0800, Tom Stellard via Release-testers wrote: Hi, I've posted the proposed 14.0.0 Release Schedule here: https://llvm.discourse.group/t/llvm-14-0-0-release-schedule/5846 Any reason this isn't in the 'release testers' categor

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-20 Thread Pavel Labath via lldb-dev
On 20/01/2022 00:30, Greg Clayton wrote: I also vote to remove and simplify. Sounds like it's settled then. I'll fire up my sed scripts. On 20/01/2022 01:38, Greg Clayton wrote: On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: If we got rid of this, we could simplify the logging calls eve

Re: [lldb-dev] [Release-testers] LLVM 14.0.0 Release Schedule

2022-01-20 Thread Michał Górny via lldb-dev
On Wed, 2022-01-19 at 21:23 -0800, Tom Stellard via Release-testers wrote: > Hi, > > I've posted the proposed 14.0.0 Release Schedule here: > https://llvm.discourse.group/t/llvm-14-0-0-release-schedule/5846 > Any reason this isn't in the 'release testers' category you told us to follow? -- Be

[lldb-dev] LLVM 14.0.0 Release Schedule

2022-01-19 Thread Tom Stellard via lldb-dev
Hi, I've posted the proposed 14.0.0 Release Schedule here: https://llvm.discourse.group/t/llvm-14-0-0-release-schedule/5846 -Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-19 Thread Greg Clayton via lldb-dev
> On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: > > Hi all, > > In case you haven't noticed, I'd like to draw your attention to the in-flight > patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) > whose goal clean up/improve/streamline the logging infrastructure.

Re: [lldb-dev] Multiple platforms with the same name

2022-01-19 Thread Greg Clayton via lldb-dev
> On Jan 19, 2022, at 4:28 AM, Pavel Labath wrote: > > On 19/01/2022 00:38, Greg Clayton wrote: >> Platforms can contain connection specific setting and data. You might want >> to create two different "remote-linux" platforms and connect each one to a >> different remote linux machine. Each t

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-19 Thread Greg Clayton via lldb-dev
I also vote to remove and simplify. > On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: > > Hi all, > > In case you haven't noticed, I'd like to draw your attention to the in-flight > patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) > whose goal clean up/improve/str

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-19 Thread Jonas Devlieghere via lldb-dev
> On Jan 19, 2022, at 10:25 AM, Jim Ingham wrote: > > > >> On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: >> >> Hi all, >> >> In case you haven't noticed, I'd like to draw your attention to the >> in-flight patches (https://reviews.llvm.org/D117382, >> https://reviews.llvm.org/D117490)

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-19 Thread Jim Ingham via lldb-dev
> On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: > > Hi all, > > In case you haven't noticed, I'd like to draw your attention to the in-flight > patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) > whose goal clean up/improve/streamline the logging infrastructure.

Re: [lldb-dev] Multiple platforms with the same name

2022-01-19 Thread Jim Ingham via lldb-dev
> On Jan 19, 2022, at 4:28 AM, Pavel Labath wrote: > > On 19/01/2022 00:38, Greg Clayton wrote: >> Platforms can contain connection specific setting and data. You might want >> to create two different "remote-linux" platforms and connect each one to a >> different remote linux machine. Each t

[lldb-dev] Is GetLogIf**All**CategoriesSet useful?

2022-01-19 Thread Pavel Labath via lldb-dev
Hi all, In case you haven't noticed, I'd like to draw your attention to the in-flight patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) whose goal clean up/improve/streamline the logging infrastructure. I'm don't want go into technical details here (they're on the

Re: [lldb-dev] Multiple platforms with the same name

2022-01-19 Thread Pavel Labath via lldb-dev
On 19/01/2022 00:38, Greg Clayton wrote: Platforms can contain connection specific setting and data. You might want to create two different "remote-linux" platforms and connect each one to a different remote linux machine. Each target which uses this platform would each be able to fetch files,

Re: [lldb-dev] Source-level stepping with emulated instructions

2022-01-19 Thread Kjell Winblad via lldb-dev
; and it seems like I can use it to get the behavior we want so adding a “don’t stop in me” check specific to our architecture seems like a good solution for us. Best regards, Kjell On Tue, 18 Jan 2022 at 19:42, Jim Ingham via lldb-dev wrote: > > I think that description was a bit too muc

Re: [lldb-dev] Multiple platforms with the same name

2022-01-18 Thread Greg Clayton via lldb-dev
Platforms can contain connection specific setting and data. You might want to create two different "remote-linux" platforms and connect each one to a different remote linux machine. Each target which uses this platform would each be able to fetch files, resolve symbol files, get OS version/build

Re: [lldb-dev] Source-level stepping with emulated instructions

2022-01-18 Thread Jim Ingham via lldb-dev
“should stop here” machinery to do what you want. Jim > On Jan 18, 2022, at 10:28 AM, Jim Ingham via lldb-dev > wrote: > > > >> On Jan 16, 2022, at 11:23 PM, Pavel Labath wrote: >> >> Hi Kjell, >> >> if you say these instructions are similar to

Re: [lldb-dev] Source-level stepping with emulated instructions

2022-01-18 Thread Jim Ingham via lldb-dev
ted instruction region doesn’t strictly need to be a function call, provided you know how to produce a thread plan that will step out of it. Jim > > pl > > On 15/01/2022 07:49, Kjell Winblad via lldb-dev wrote: >> Hi! >> I'm implementing LLDB support for a ne

[lldb-dev] Multiple platforms with the same name

2022-01-17 Thread Pavel Labath via lldb-dev
Hello all, currently our code treats platform name more-or-less as a unique identifier (e.g. Platform::Find returns at most one platform instance --the first one it finds). This is why I was surprised that the "platform select" CLI command always creates a new instance of the given platform

Re: [lldb-dev] Source-level stepping with emulated instructions

2022-01-16 Thread Pavel Labath via lldb-dev
e functions (names, line numbers, whatever...) pl On 15/01/2022 07:49, Kjell Winblad via lldb-dev wrote: Hi! I'm implementing LLDB support for a new processor architecture that the company I'm working for has created. The processor architecture has a few emulated instructions. An emulate

Re: [lldb-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2022-01-14 Thread Tom Stellard via lldb-dev
On 12/17/21 13:15, Tom Stellard wrote: Hi, Here is a proposal for a new automated workflow for managing parts of the release process.  I've been experimenting with this over the past few releases and now that we have migrated to GitHub issues, it would be possible for us to implement this in th

[lldb-dev] Source-level stepping with emulated instructions

2022-01-14 Thread Kjell Winblad via lldb-dev
Hi! I'm implementing LLDB support for a new processor architecture that the company I'm working for has created. The processor architecture has a few emulated instructions. An emulated instruction works by jumping to a specific address that contains the start of a block of instructions that emulat

Re: [lldb-dev] [EXTERNAL] LLDB Windows on Arm64 buildbot

2022-01-14 Thread Stella Stamenova via lldb-dev
That's very exciting! Please let me know if you run into any issues I could help with. Thanks, -Stella From: Omair Javaid Sent: Friday, January 14, 2022 2:12 PM To: mailing list lldb-dev Cc: Stella Stamenova Subject: [EXTERNAL] LLDB Windows on Arm64 buildbot You don't often get email from o

[lldb-dev] LLDB Windows on Arm64 buildbot

2022-01-14 Thread Omair Javaid via lldb-dev
Hi, This is to notify that we are in process of setting up a LLDB Windows on Arm64 buildbot which will help share the load of maintenance of LLDB Windows platform support. Should you have any query or suggestions please feel free to contact us. Thanks! -- Omair Javaid www.linaro.org ___

[lldb-dev] problems using EvaluateExpression in lldb, when it creates new object

2022-01-14 Thread fhjiwerfghr fhiewrgfheir via lldb-dev
I'm sorry in advance, if it's not a correct mailing list, there doesn't seem to be lldb-usage mailing list. I'm writing a pretty-printer python script, which - to cut to the chase, pretty prints members of a class by using EvaluateExpression and creating new object inside it. It doesn't seem to wo

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-13 Thread Jim Ingham via lldb-dev
You are really going to make a lldb_private::CompilerType, since that’s what backs the Type & ultimately the SBTypes. There’s a self-contained example where we make a CompilerType to represent the pairs in the synthetic child provider for NSDictionaries in the function GetLLDBNSPairType in NSD

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-13 Thread Michał Górny via lldb-dev
On Wed, 2022-01-12 at 11:22 -0800, Jim Ingham wrote: > If we can’t always get our hands on the siginfo type, we will have to cons > that type up by hand.  But we would have had to do that if we were > implementing this feature in the expression parser anyway, and we already > hand-make types to

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-13 Thread Michał Górny via lldb-dev
On Wed, 2022-01-12 at 11:22 -0800, Jim Ingham wrote: > > > On Jan 12, 2022, at 4:28 AM, Pavel Labath wrote: > > > > I kinda like the cleanliness (of the design, not the implementation) of a > > $siginfo variable, but you're right that implementing it would be tricky (I > > guess we'd have to w

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-13 Thread Michał Górny via lldb-dev
On Wed, 2022-01-12 at 13:28 +0100, Pavel Labath wrote: > > This wouldn't solve the problem of writing to the siginfo struct, but I > am not sure if this is a use case Michał is actually trying to solve > right now (?) If it is then, maybe this could be done through a separate > command, as we c

[lldb-dev] lldb-dev mailing list moving to LLVM Discourse

2022-01-12 Thread Tanya Lattner via lldb-dev
The lldb-dev mailing list will be moved to LLVM Discourse under the “LLDB” category (under Subprojects). All archives will be migrated. This list will be no longer be in use starting February 1, 2022. Please see this blog post for all details: https://blog.llvm.org/posts/2022-01-07-moving-to-dis

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-12 Thread Jim Ingham via lldb-dev
nd, or integrated into the existing process/thread continue > commands. (thread continue --signal SIGFOO => "continue with SIGFOO"; thread > continue --siginfo $47 => continue with siginfo in $47 ???) > > pl > > On 12/01/2022 01:07, Jim Ingham via lldb-dev wrote

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-12 Thread Pavel Labath via lldb-dev
"continue with SIGFOO"; thread continue --siginfo $47 => continue with siginfo in $47 ???) pl On 12/01/2022 01:07, Jim Ingham via lldb-dev wrote: I would not do this with the expression parser. First off, the expression parser doesn’t know how to do anything JIT code that will run

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-11 Thread Jim Ingham via lldb-dev
This sentence makes no sense, it was a remnant of a previous draft, which included the option to do: (lldb) platform write —field name —value expression —field other_name —value other_expression But that would require people to quote their expressions to get them past the command parser, which

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-11 Thread Jim Ingham via lldb-dev
ard via lldb-dev > wrote: > > > You should use Hg for this instead of Hc. Hc is used for step/continue, while > Hg is used for everything else. > > >> -Original Message- >> From: lldb-dev On Behalf Of Michal Górny >> via lldb-dev >> Sen

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-11 Thread Michał Górny via lldb-dev
On Tue, 2022-01-11 at 15:48 +, Ted Woodward wrote: > You should use Hg for this instead of Hc. Hc is used for step/continue, while > Hg is used for everything else. > Thanks for the explanation. -- Best regards, Michał Górny ___ lldb-dev mailing

Re: [lldb-dev] RFC: siginfo reading/writing support

2022-01-11 Thread Ted Woodward via lldb-dev
You should use Hg for this instead of Hc. Hc is used for step/continue, while Hg is used for everything else. > -Original Message- > From: lldb-dev On Behalf Of Michal Górny > via lldb-dev > Sent: Tuesday, January 11, 2022 6:38 AM > To: lldb-dev@lists.llvm.org >

[lldb-dev] RFC: siginfo reading/writing support

2022-01-11 Thread Michał Górny via lldb-dev
Hello, TL;DR: I'd like to implement at least partial support for reading/writing siginfo via LLDB. I can't think of a better approach than copying the GDB's idea of "magical" $_siginfo variable that works through the expression evaluator. I'd like to know your opinion/ideas. POSIX defines a s

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2022-01-08 Thread Tom Stellard via lldb-dev
On 1/1/22 12:54, Sean McBride wrote: On 30 Nov 2021, at 1:07, Tom Stellard via cfe-dev wrote: Testers can begin testing and uploading binaries. It's been over a month since 13.0.1-rc1, and, as has been the case for many previous releases, there are no macOS binaries. And chance we'll see so

Re: [lldb-dev] [cfe-dev] [llvm-dev] Subscribing to GitHub issue labels

2022-01-05 Thread Fāng-ruì Sòng via lldb-dev
On Wed, Jan 5, 2022 at 8:56 PM Mehdi AMINI via cfe-dev wrote: > > > > On Wed, Jan 5, 2022 at 2:28 PM Tom Stellard via llvm-dev > wrote: >> >> Hi, >> >> We have a system now for subscribing to GitHub issue labels. If you >> want to subscribe to a label, request membership in the >> issue-subscri

[lldb-dev] Subscribing to GitHub issue labels

2022-01-05 Thread Tom Stellard via lldb-dev
Hi, We have a system now for subscribing to GitHub issue labels. If you want to subscribe to a label, request membership in the issue-subscribers-$LABEL_NAME team from https://github.com/orgs/llvm/teams. If the team does not exist yet, file an issue and assign it to me and I will create the tea

Re: [lldb-dev] RFC: How to handle non-address bits in the output of "memory read"

2022-01-04 Thread Stephen Hines via lldb-dev
Hi David, Sending this message again as I'm now back from vacation (and I was finally able to subscribe to lldb-dev - non-subscribers are prevented from sending email to it). On Fri, Dec 10, 2021 at 1:56 AM David Spickett wrote: > (Peter and Stephen on CC since you've previously asked about thi

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-24 Thread Renato Golin via lldb-dev
Ah, awesome, thanks! On Fri, 24 Dec 2021, 03:11 Tom Stellard, wrote: > On 12/23/21 09:53, Renato Golin wrote: > > On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org > wrote: > > > > * On an existing issue or a newly created iss

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-23 Thread Tom Stellard via lldb-dev
On 12/23/21 09:53, Renato Golin wrote: On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: * On an existing issue or a newly created issue, a user who wants to backport one or more commits to the release branch adds a comment: /cherry-pic

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-23 Thread Renato Golin via lldb-dev
On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > * On an existing issue or a newly created issue, a user who wants to > backport > one or more commits to the release branch adds a comment: > > /cherry-pick <..> > Hi Tom, Would this be *any* user or use

[lldb-dev] Are any LLVM components affected by the recent log4j issues?

2021-12-22 Thread Kristof Beyls via lldb-dev
As one of the points of contact at CERT for LLVM, I've received messages from CERT asking if LLVM is affected by any of the recent log4j vulnerabilities: *CVE-2021-45105*, *CVE-2021-4104*, *CVE-2021-45046* and *CVE-2021-44228*. It seems CERT is reaching out to every single vendor registered with th

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-20 Thread Tom Stellard via lldb-dev
On 12/20/21 18:21, Mehdi AMINI wrote: On Mon, Dec 20, 2021 at 3:24 PM Tom Stellard mailto:tstel...@redhat.com>> wrote: On 12/20/21 09:16, Tom Stellard wrote: > On 12/18/21 15:04, David Blaikie wrote: >> >> >> On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard mailto:tstel...@

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-20 Thread Philip Reames via lldb-dev
On 12/20/21 3:24 PM, Tom Stellard via llvm-dev wrote: On 12/20/21 09:16, Tom Stellard wrote: On 12/18/21 15:04, David Blaikie wrote: On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard > wrote:     On 12/17/21 16:47, David Blaikie wrote: > Sounds pretty good to me

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-20 Thread Tom Stellard via lldb-dev
On 12/20/21 09:16, Tom Stellard wrote: On 12/18/21 15:04, David Blaikie wrote: On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard mailto:tstel...@redhat.com>> wrote:     On 12/17/21 16:47, David Blaikie wrote: > Sounds pretty good to me - wouldn't mind knowing more about/a good summary of the

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-20 Thread Tom Stellard via lldb-dev
On 12/18/21 15:04, David Blaikie wrote: On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard mailto:tstel...@redhat.com>> wrote: On 12/17/21 16:47, David Blaikie wrote: > Sounds pretty good to me - wouldn't mind knowing more about/a good summary of the effects of this on project/repo/etc not

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-18 Thread David Blaikie via lldb-dev
On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard wrote: > On 12/17/21 16:47, David Blaikie wrote: > > Sounds pretty good to me - wouldn't mind knowing more about/a good > summary of the effects of this on project/repo/etc notifications that > Mehdi's mentioning. (be good to have a write up of the exp

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-17 Thread Tom Stellard via lldb-dev
On 12/17/21 16:47, David Blaikie wrote: Sounds pretty good to me - wouldn't mind knowing more about/a good summary of the effects of this on project/repo/etc notifications that Mehdi's mentioning. (be good to have a write up of the expected impact/options to then discuss - from the thread so f

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-17 Thread David Blaikie via lldb-dev
Sounds pretty good to me - wouldn't mind knowing more about/a good summary of the effects of this on project/repo/etc notifications that Mehdi's mentioning. (be good to have a write up of the expected impact/options to then discuss - from the thread so far I understand some general/high level conce

Re: [lldb-dev] [Release-testers] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-17 Thread Tom Stellard via lldb-dev
On 12/17/21 13:25, Mehdi AMINI wrote: Hi, On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via Release-testers mailto:release-test...@lists.llvm.org>> wrote: Hi, Here is a proposal for a new automated workflow for managing parts of the release process.  I've been experimenting wit

[lldb-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

2021-12-17 Thread Tom Stellard via lldb-dev
Hi, Here is a proposal for a new automated workflow for managing parts of the release process. I've been experimenting with this over the past few releases and now that we have migrated to GitHub issues, it would be possible for us to implement this in the main repo. The workflow is pretty str

Re: [lldb-dev] [cfe-dev] 13.0.1 Release Update

2021-12-16 Thread Anton Korobeynikov via lldb-dev
And for the record, here is the milestone: https://github.com/llvm/llvm-project/milestone/2 On Fri, Dec 17, 2021 at 5:58 AM Tom Stellard via cfe-dev wrote: > > Hi, > > I'm back on track with the release after the buzilla migration, so I'm > going to accept backport requests until Monday, Dec 20,

[lldb-dev] 13.0.1 Release Update

2021-12-16 Thread Tom Stellard via lldb-dev
Hi, I'm back on track with the release after the buzilla migration, so I'm going to accept backport requests until Monday, Dec 20, and then I'll try to tag -rc2 on Wed Dec 21. If you have patches you want backported to the release/13.x branch, please file an issue and add it to the "LLVM 13.0.1

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-14 Thread Ed Maste via lldb-dev
On Tue, 14 Dec 2021 at 10:58, Pavel Labath via lldb-dev wrote: > > So how would this be represented in lldb? Would there be any threads, > registers? Just a process with a bunch of modules ? Using GDB (kgdb) as an example - it lists a thread for every kernel/userspace thread. Fo

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-14 Thread Pavel Labath via lldb-dev
On 10/12/2021 11:12, Michał Górny wrote: On Mon, 2021-12-06 at 14:28 +0100, Pavel Labath wrote: The live kernel debugging sounds... scary. Can you explain how would this actually work? Like, what would be the supported operations? I presume you won't be able to actually "stop" the kernel, but wh

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-10 Thread Michał Górny via lldb-dev
On Mon, 2021-12-06 at 14:28 +0100, Pavel Labath wrote: > The live kernel debugging sounds... scary. Can you explain how would > this actually work? Like, what would be the supported operations? I > presume you won't be able to actually "stop" the kernel, but what will > you actually be able to d

[lldb-dev] RFC: How to handle non-address bits in the output of "memory read"

2021-12-10 Thread David Spickett via lldb-dev
(Peter and Stephen on CC since you've previously asked about this sort of thing) This relates to https://reviews.llvm.org/D103626 and other recent patches about non-address bits. On AArch64 we've got a few extensions that use "non address bits". These are bits beyond the (in most cases) 48 bit vi

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-06 Thread Pavel Labath via lldb-dev
On 30/11/2021 14:49, Michał Górny via lldb-dev wrote: Hi, I'm working on a FreeBSD-sponsored project aiming at improving LLDB's support for debugging FreeBSD kernel to achieve feature parity with KGDB. As a part of that, I'd like to improve LLDB's ability of working w

Re: [lldb-dev] No script in lldb of build

2021-12-06 Thread David Spickett via lldb-dev
n hopefully help from there. On Sun, 5 Dec 2021 at 20:02, Pi Pony via lldb-dev wrote: > > Hello, > > I build lldb for macOS and tried to get into script but I get this error > message: there is no embedded script interpreter in this mode. > > I appreciate any help you can pro

[lldb-dev] No script in lldb of build

2021-12-05 Thread Pi Pony via lldb-dev
Hello, I build lldb for macOS and tried to get into script but I get this error message: there is no embedded script interpreter in this mode. I appreciate any help you can provide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org

[lldb-dev] Can't build on Mac after https://reviews.llvm.org/D113650

2021-12-02 Thread Greg Clayton via lldb-dev
Some recent python changes have stopped by cmake configure from working on fresh checkout on macOS. Details in the comments of the diff in https://reviews.llvm.org/D113650 as to how I am configuring cmake. If anyone has any example of how to properly set the python stuff to work around the issu

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-12-02 Thread Tom Stellard via lldb-dev
Re-sending and dropping the Fedora list, which I accidentally cc'd. On 12/2/21 08:35, Tom Stellard wrote: On 12/2/21 06:45, Nemanja Ivanovic wrote: Hi Tom, would it be OK to directly send you git hashes for patches we would like back ported until the bugzilla transition completes? Yes, tha

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-12-02 Thread Tom Stellard via lldb-dev
On 12/2/21 06:45, Nemanja Ivanovic wrote: Hi Tom, would it be OK to directly send you git hashes for patches we would like back ported until the bugzilla transition completes? Yes, that's fine. -Tom On Tue, Nov 30, 2021 at 1:08 AM Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org>> w

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-02 Thread David Spickett via lldb-dev
> 1. The (older) "full memory" coredumps that use an ELF container. > > 2. The (newer) minidumps that dump only the active memory and use a custom format. Maybe a silly question, is the "minidumps" here the same sort of minidump as lldb already supports (https://chromium.googlesource.com/breakpad/

Re: [lldb-dev] [llvm-dev] Release 13.0.1-rc1 has been tagged

2021-12-02 Thread Dimitry Andric via lldb-dev
On 30 Nov 2021, at 07:07, Tom Stellard via llvm-dev wrote: > > I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. For 13.0.1 rc1, I have built and tested on both FreeBSD 12 and 13. No additional patches were needed. For the 32-builds I used -no-flang, as flang is curren

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-02 Thread David Spickett via lldb-dev
> Right now, the idea is that when the kernel crashes, the developer can > take the vmcore file use LLDB to look the kernel state up. Thanks for the explanation. (FWIW your first email is clear now that I read it properly but this still helped me :)) > 2) How to integrate "live kernel" support in

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-02 Thread Michał Górny via lldb-dev
On Thu, 2021-12-02 at 09:40 +, David Spickett wrote: > Can you give an example workflow of how these core files are used by a > developer? For some background. Right now, the idea is that when the kernel crashes, the developer can take the vmcore file use LLDB to look the kernel state up. Ini

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-02 Thread David Spickett via lldb-dev
e plugin? On Tue, 30 Nov 2021 at 19:59, Michał Górny via lldb-dev wrote: > > Hi, > > I'm working on a FreeBSD-sponsored project aiming at improving LLDB's > support for debugging FreeBSD kernel to achieve feature parity with > KGDB. As a part of that, I'd like to

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-12-02 Thread Diana Picus via lldb-dev
Hi, Uploaded armv7 & aarch64 Ubuntu binaries and also aarch64 Windows: baa53279469e387f333cd90d9e8a30973c8a5d884dd893862435967d40c1a0e9 clang+llvm-13.0.1-rc1-aarch64-linux-gnu.tar.xz 1a523df1cd1a8f64158f602a4e2ce1ad845d322d9dda11225b3d96b2c957203e clang+llvm-13.0.1-rc1-armv7a-linux-gnueabihf.tar

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-11-30 Thread Brooks Davis via lldb-dev
On Tue, Nov 30, 2021 at 01:07:33PM -0800, Tom Stellard wrote: > On 11/30/21 12:35, Brooks Davis wrote: > > On Mon, Nov 29, 2021 at 10:07:52PM -0800, Tom Stellard via cfe-dev wrote: > >> Hi, > >> > >> I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. > > > > There don't see

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-11-30 Thread Tom Stellard via lldb-dev
On 11/30/21 12:35, Brooks Davis wrote: On Mon, Nov 29, 2021 at 10:07:52PM -0800, Tom Stellard via cfe-dev wrote: Hi, I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. There don't seem be llvm-project tarballs. I see: https://github.com/llvm/llvm-project/releases/dow

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-11-30 Thread Brooks Davis via lldb-dev
On Mon, Nov 29, 2021 at 10:07:52PM -0800, Tom Stellard via cfe-dev wrote: > Hi, > > I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. There don't seem be llvm-project tarballs. I see: https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.1-rc1/llvm-13.0.1r

[lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-11-30 Thread Michał Górny via lldb-dev
Hi, I'm working on a FreeBSD-sponsored project aiming at improving LLDB's support for debugging FreeBSD kernel to achieve feature parity with KGDB. As a part of that, I'd like to improve LLDB's ability of working with kernel coredumps ("vmcores"), plus add the ability to read kernel memory via sp

Re: [lldb-dev] Release 13.0.1-rc1 has been tagged

2021-11-30 Thread Tom Stellard via lldb-dev
+ Release-testers On 11/29/21 22:07, Tom Stellard wrote: Hi, I've tagged 13.0.1-rc1.  Testers can begin testing and uploading binaries. There is still time to submit fixes for the final 13.0.1.  I'll give more details about timelines and how to do this once the bugzilla migration is complete. 

Re: [lldb-dev] [cfe-dev] Release 13.0.1-rc1 has been tagged

2021-11-30 Thread Hans Wennborg via lldb-dev
On Tue, Nov 30, 2021 at 7:08 AM Tom Stellard via cfe-dev wrote: > > Hi, > > I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. > > There is still time to submit fixes for the final 13.0.1. I'll give more > details about timelines and how to do this once the bugzilla migrat

[lldb-dev] Release 13.0.1-rc1 has been tagged

2021-11-29 Thread Tom Stellard via lldb-dev
Hi, I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries. There is still time to submit fixes for the final 13.0.1. I'll give more details about timelines and how to do this once the bugzilla migration is complete. Currently, bugzilla is read-only, so we can't submit any f

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

2021-11-24 Thread Pavel Labath via lldb-dev
mething this work needs to consider. Just me relating the idea to something I have more experience with and has some parallels with the qemu-user idea. On Fri, 5 Nov 2021 at 14:08, Pavel Labath via lldb-dev wrote: On 04/11/2021 22:46, Jessica Clarke via lldb-dev wrote: On Fri, Oct 29, 2021 at 05:55:

[lldb-dev] [Bug 52591] New: LLDB failed to lookup method names in NativePDB plugin

2021-11-23 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=52591 Bug ID: 52591 Summary: LLDB failed to lookup method names in NativePDB plugin Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhan

[lldb-dev] [Bug 52585] New: Crash when when genarating backtrace

2021-11-22 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=52585 Bug ID: 52585 Summary: Crash when when genarating backtrace Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement P

  1   2   3   4   5   6   7   8   9   10   >