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

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

-- 
Best regards,
Michał Górny

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

[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 even 
further and have something like:>> Log *log =

GetLog(LLDBLog::Process);


Can a template function deduce the log type from an argument? 
Wouldn't this have to be:


Log *log = GetLog(LLDBLog::Process);

That is why I was hinting if we want to just use the enum class 
itself:


Log *log = LLDBLog::GetLog(LLDBLog::Process);

The template class in your second patch seems cool, but I don't 
understand how it worked without going and reading up on templates

in C++ and spending 20 minutes trying to wrap my brain around it.

Template functions have always been able to deduce template arguments.
Pretty much the entire c++ standard library is made of template
functions, but you don't see <> spelled out everywhere. Class templates
have not been able to auto-deduce template arguments until c++17, and I
am still not really clear on how that works.

The way that patch works is that you have one template function
`LogChannelFor`, which ties the enum to a specific channel class, and
then another one (GetLogIfAny), which returns the actual log object (and
uses the first one to obtain the channel).

But none of this is fundamentally tied to templates. One could achieve
the same thing by overloading the GetLogIfAny function (one overload for
each type). The template just saves a bit of repetition. This way, the
only thing you need to do when defining a new log channel, is to provide
the LogChannelFor function.



Or do we just switch to a dedicated log class with unique methods:

class LLDBLog: public Log { Log *Process() { return GetLog(1u << 0);
} Log *Thread() { return GetLog(1u << 1); } };

and avoid all the enums? Then we can't ever feed a bad enum or 
#define  into the wrong log class.


That could work too, and would definitely have some advantages -- for
instance we could prefix each message with the log channel it was going
to. The downside is that we would lose the ability to send one message 
to multiple log channels at once, and I believe that some (Jim?) value 
that functionality.


pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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' category you told us to
follow?



I'm still trying to figure out the best place to post messages.  For the
schedule announcement I wanted to make sure it went out to the whole project
and not just the release testers.

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

[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  wrote: 
>>> If we got rid of this, we could simplify the logging calls even further and 
>>> have something like:>> Log *log =
>>> GetLog(LLDBLog::Process);
>> Can a template function deduce the log type from an argument? Wouldn't this 
>> have to be:
>> Log *log = GetLog(LLDBLog::Process);
>> That is why I was hinting if we want to just use the enum class itself:
>> Log *log = LLDBLog::GetLog(LLDBLog::Process);
>> The template class in your second patch seems cool, but I don't understand 
>> how it worked without going and reading up on templates
>> in C++ and spending 20 minutes trying to wrap my brain around it.
> Template functions have always been able to deduce template arguments.
> Pretty much the entire c++ standard library is made of template
> functions, but you don't see <> spelled out everywhere. Class templates
> have not been able to auto-deduce template arguments until c++17, and I
> am still not really clear on how that works.
> 
> The way that patch works is that you have one template function
> `LogChannelFor`, which ties the enum to a specific channel class, and
> then another one (GetLogIfAny), which returns the actual log object (and
> uses the first one to obtain the channel).
> 
> But none of this is fundamentally tied to templates. One could achieve
> the same thing by overloading the GetLogIfAny function (one overload for
> each type). The template just saves a bit of repetition. This way, the
> only thing you need to do when defining a new log channel, is to provide
> the LogChannelFor function.
> 
>> Or do we just switch to a dedicated log class with unique methods:
>> class LLDBLog: public Log { Log *Process() { return GetLog(1u << 0);
>> } Log *Thread() { return GetLog(1u << 1); } };
>> and avoid all the enums? Then we can't ever feed a bad enum or #define  into 
>> the wrong log class.
> 
> That could work too, and would definitely have some advantages -- for
> instance we could prefix each message with the log channel it was going
> to. The downside is that we would lose the ability to send one message to 
> multiple log channels at once, and I believe that some (Jim?) value that 
> functionality.

I think I’m just quibbling about terminology, I don’t think it’s possible for 
one site to send its log message to two channels in a single go.  That would be 
like “lldb types” and “dwarf info” for a single log statement.
Anyway, that’s not something I see as particularly useful.

What is useful is to say “this message goes out on the lldb channel if any of 
these categories (“step” and “expr” for instance) is set.”  I don’t really 
think of that as sending the message to multiple channels, since it’s only 
going to go out once, but the test is broader.

But, IIUC, Greg’s proposal would also make that impossible as well, so I’m 
still against it…

Jim


> 
> pl

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

[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 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 even further 
 and have something like:>> Log *log =
 GetLog(LLDBLog::Process);
>>> Can a template function deduce the log type from an argument? Wouldn't this 
>>> have to be:
>>> Log *log = GetLog(LLDBLog::Process);
>>> That is why I was hinting if we want to just use the enum class itself:
>>> Log *log = LLDBLog::GetLog(LLDBLog::Process);
>>> The template class in your second patch seems cool, but I don't understand 
>>> how it worked without going and reading up on templates
>>> in C++ and spending 20 minutes trying to wrap my brain around it.
>> Template functions have always been able to deduce template arguments.
>> Pretty much the entire c++ standard library is made of template
>> functions, but you don't see <> spelled out everywhere. Class templates
>> have not been able to auto-deduce template arguments until c++17, and I
>> am still not really clear on how that works.
>> 
>> The way that patch works is that you have one template function
>> `LogChannelFor`, which ties the enum to a specific channel class, and
>> then another one (GetLogIfAny), which returns the actual log object (and
>> uses the first one to obtain the channel).
>> 
>> But none of this is fundamentally tied to templates. One could achieve
>> the same thing by overloading the GetLogIfAny function (one overload for
>> each type). The template just saves a bit of repetition. This way, the
>> only thing you need to do when defining a new log channel, is to provide
>> the LogChannelFor function.
>> 
>>> Or do we just switch to a dedicated log class with unique methods:
>>> class LLDBLog: public Log { Log *Process() { return GetLog(1u << 0);
>>> } Log *Thread() { return GetLog(1u << 1); } };
>>> and avoid all the enums? Then we can't ever feed a bad enum or #define  
>>> into the wrong log class.
>> 
>> That could work too, and would definitely have some advantages -- for
>> instance we could prefix each message with the log channel it was going
>> to. The downside is that we would lose the ability to send one message to 
>> multiple log channels at once, and I believe that some (Jim?) value that 
>> functionality.
> 
> I think I’m just quibbling about terminology, I don’t think it’s possible for 
> one site to send its log message to two channels in a single go.  That would 
> be like “lldb types” and “dwarf info” for a single log statement.
> Anyway, that’s not something I see as particularly useful.
> 
> What is useful is to say “this message goes out on the lldb channel if any of 
> these categories (“step” and “expr” for instance) is set.”  I don’t really 
> think of that as sending the message to multiple channels, since it’s only 
> going to go out once, but the test is broader.
> 
> But, IIUC, Greg’s proposal would also make that impossible as well, so I’m 
> still against it…
> 
> Jim
> 
> 
>> 
>> pl

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 Arm platform is missing a vscode
adapter plugin required to make lldb-vscode tool work on Arm/Windows
platform. Similar adapter plugin is available for Windows x64 through third
parties but I am wondering if there is an official version of the same
plugin which can be packaged after porting for Windows on Arm.

I ll really appreciate any sort of help/pointer to accelerate further
progress.

Thanks!

--
Omair Javaid
www.linaro.org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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/lldb/tools/lldb-vscode/README.md
>  
> 
> 
> If I understood correctly Windows on Arm platform is missing a vscode adapter 
> plugin required to make lldb-vscode tool work on Arm/Windows platform. 
> Similar adapter plugin is available for Windows x64 through third parties but 
> I am wondering if there is an official version of the same plugin which can 
> be packaged after porting for Windows on Arm.

Right now we don’t distribute a lldb-vscode through the marketplace so you just 
need to build it yourself and then create the directory as mentioned in the 
readme.

Basically you just need to download the LLDB sources to a Windows on Arm 
machine and build “lldb-vscode”. Then you take the “lldb-vscode.exe” binary and 
the LLDB DLL and put then into the extension’s bin folder. Then make sure that 
you can launch the program from the terminal and make sure it finds the DLL 
right next to the program

I am not sure if where the VSCode extensions live on a windows user folder, but 
the readme is saying:

~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin

So you would want to end up with:

~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/lldb-vscode.exe
~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/lldb.dll 

(not sure of the name of the lldb library name on windows)

And then copy the package.json to the folder:

cp package.json ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0

Then you should be able to restart your VS code IDE and the extension should be 
available. It is important to make sure that the program lauches from the 
command line to make sure that the program is able to locate the lldb shared 
library (DLL). If you launch the program and it doesn’t complain, it will just 
sit there waiting for input. If it can’t find the DLL, then it should cause an 
error and you will need to figure where the DLL needs to be relative to the 
program. I am not familiar with exactly how this works on windows for a given 
EXE and how it locates the DLLs the main executable needs.

Let me know if you are able to get things working!

Greg

> 
> I ll really appreciate any sort of help/pointer to accelerate further 
> progress.
> 
> Thanks!
> 
> --
> Omair Javaid
> www.linaro.org 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev