[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

[lldb-dev] LLDB Windows on Arm64 buildbot

[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 mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] who is maintaining lldb-x86_64-debian

[Omair Javaid via lldb-dev]

Hi Jan,
On Thu, 2 Sept 2021 at 17:29, Jan Kratochvil 
wrote:

> On Thu, 02 Sep 2021 12:42:37 +0200, Raphael “Teemperor” Isemann via
> lldb-dev wrote:
> > If this is about the TestGuiBasicDebug failures, then that test is also
> > failing on other bots. I personally would vote to disable the test as
> that
> > part of the test is flakey since its introduction (which was during this
> > GSoC).
>
> Yes, in the last month or so there have been some random failures on this
otherwise very stable buildbot so I was wondering if someone is looking
after and taking care of these issues or not.

There are multiple racy testcases. I have setup alert only if all last
> 5 builds failed. That is a longterm reliable enough threshold.
>
> For https://lab.llvm.org/staging/#/builders/16 = lldb-x86_64-fedora:
>
> https://lab.llvm.org/staging/api/v2/builders/16/builds?limit=5&order=-number
> "state_string": "build successful",
>
This is helpful. Thanks!


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

[lldb-dev] who is maintaining lldb-x86_64-debian

[Omair Javaid via lldb-dev]

Hi

There have been sporadic failures due to timeouts on lldb-x86_64-debian
. I don't see Pavel maintingi
it now. Does anyone know who's looking after this bot?

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] [cfe-dev] [llvm-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?

[Omair Javaid via lldb-dev]

On Wed, 14 Apr 2021 at 20:41, Tom Stellard  wrote:

> On 4/14/21 5:50 AM, Omair Javaid wrote:
> > Ping!
> >
> > Tom, any update on this?
> >
>
> Yes, thanks for reminding me.  The infrastructure is in place now, so
> we can start adding more bots.  Do you have a bot that you want to add?
>
> -Tom
>
I intend to set up two new release bots for LLVM AArch64 and Arm release.
Do you have a reference release bot that I can replicate for my use-case?


> > On Mon, 15 Feb 2021 at 20:02, Nemanja Ivanovic  > wrote:
> >
> > We are interested in doing this for PPC as well. Not likely for all
> of our bots, but one or two select ones.
> >
> > On Fri, Feb 12, 2021 at 11:51 AM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org > wrote:
> >
> > On 2/12/21 1:49 AM, Omair Javaid wrote:
> >  > Hi Tom,
> >  >
> >  > We at Linaro are maintaining LLVM Arm/AArch64 buildbots and
> want a host buildbot for testing of release branches.
> >  >
> >
> > OK, that's great.
> >
> >  > Kindly share the steps to do this. Do we have to host
> separate builbots for tracking release branches or is it possible to track
> multiple branches by existing buildbots assuming traffic on release
> branches is less frequent?
> >  >
> >
> > I've submitted a patch[1] to add the infrastructure for enabling
> builders
> > on the release branch.  Once this patch or something similar
> gets applied
> > then we can start enabling individual builders.  I'll follow up
> with you
> > once this patch lands.
> >
> > -Tom
> >
> >
> > [1] https://reviews.llvm.org/D96046 <
> https://reviews.llvm.org/D96046>
> >
> >  > On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org   llvm-...@lists.llvm.org >> wrote:
> >  >
> >  > On 2/2/21 1:23 AM, Diana Picus wrote:
> >  >  > Hi Tom,
> >  >  >
> >  >  > This sounds interesting! Would this also make it
> possible to automatically get the release binaries from the buildbots, as
> opposed to manually uploading to the FTP server?
> >  >  >
> >  >
> >  > Yes, this is something I would like to do.  I think you
> could pretty easily run
> >  > the test-release.sh script on the bot.  The only issue is
> finding a way to
> >  > securely upload the binaries.
> >  >
> >  > -Tom
> >  >
> >  >  > Cheers,
> >  >  > Diana
> >  >  >
> >  >  > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org   cfe-...@lists.llvm.org >  cfe-...@lists.llvm.org   cfe-...@lists.llvm.org  >  >  >
> >  >  > Hi,
> >  >  >
> >  >  > I would like to improve the testing coverage in
> the release branch, so if you
> >  >  > are a buildbot owner and would like to enable your
> builder for the release branch,
> >  >  > let me know, and I can help get it enabled.
> >  >  >
> >  >  > Also, if you have any ideas for some more
> extensive testing that might be too
> >  >  > slow to run on the main branch, we may be able to
> enable it on the release
> >  >  > branch either running once per commit or once per
> tag.
> >  >  >
> >  >  > Thanks,
> >  >  > Tom
> >  >  >
> >  >  > ___
> >  >  > cfe-dev mailing list
> >  >  > cfe-...@lists.llvm.org 
> >  cfe-...@lists.llvm.org   cfe-...@lists.llvm.org >>
> >  >  >
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev> <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>>
> >  >  >
> >  >
> >  > ___
> >  > LLVM Developers mailing list
> >  > llvm-...@lists.llvm.org 
> >
> >  > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>>
> >  

Re: [lldb-dev] [cfe-dev] [llvm-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?

[Omair Javaid via lldb-dev]

Ping!

Tom, any update on this?

On Mon, 15 Feb 2021 at 20:02, Nemanja Ivanovic 
wrote:

> We are interested in doing this for PPC as well. Not likely for all of our
> bots, but one or two select ones.
>
> On Fri, Feb 12, 2021 at 11:51 AM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> On 2/12/21 1:49 AM, Omair Javaid wrote:
>> > Hi Tom,
>> >
>> > We at Linaro are maintaining LLVM Arm/AArch64 buildbots and want a host
>> buildbot for testing of release branches.
>> >
>>
>> OK, that's great.
>>
>> > Kindly share the steps to do this. Do we have to host separate builbots
>> for tracking release branches or is it possible to track multiple
>> branches by existing buildbots assuming traffic on release branches is less
>> frequent?
>> >
>>
>> I've submitted a patch[1] to add the infrastructure for enabling builders
>> on the release branch.  Once this patch or something similar gets applied
>> then we can start enabling individual builders.  I'll follow up with you
>> once this patch lands.
>>
>> -Tom
>>
>>
>> [1] https://reviews.llvm.org/D96046
>>
>> > On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev <
>> llvm-...@lists.llvm.org > wrote:
>> >
>> > On 2/2/21 1:23 AM, Diana Picus wrote:
>> >  > Hi Tom,
>> >  >
>> >  > This sounds interesting! Would this also make it possible to
>> automatically get the release binaries from the buildbots, as opposed to
>> manually uploading to the FTP server?
>> >  >
>> >
>> > Yes, this is something I would like to do.  I think you could
>> pretty easily run
>> > the test-release.sh script on the bot.  The only issue is finding a
>> way to
>> > securely upload the binaries.
>> >
>> > -Tom
>> >
>> >  > Cheers,
>> >  > Diana
>> >  >
>> >  > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev <
>> cfe-...@lists.llvm.org  > cfe-...@lists.llvm.org >> wrote:
>> >  >
>> >  > Hi,
>> >  >
>> >  > I would like to improve the testing coverage in the release
>> branch, so if you
>> >  > are a buildbot owner and would like to enable your builder
>> for the release branch,
>> >  > let me know, and I can help get it enabled.
>> >  >
>> >  > Also, if you have any ideas for some more extensive testing
>> that might be too
>> >  > slow to run on the main branch, we may be able to enable it
>> on the release
>> >  > branch either running once per commit or once per tag.
>> >  >
>> >  > Thanks,
>> >  > Tom
>> >  >
>> >  > ___
>> >  > cfe-dev mailing list
>> >  > cfe-...@lists.llvm.org  > cfe-...@lists.llvm.org >
>> >  > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>> >  >
>> >
>> > ___
>> > LLVM Developers mailing list
>> > llvm-...@lists.llvm.org 
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> >
>> >
>> >
>> > --
>> > Omair Javaid
>> > www.linaro.org 
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>

-- 
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] [llvm-dev] [cfe-dev] Attn Buildbot Owners: Would you like your builder to test the release branch?

[Omair Javaid via lldb-dev]

Hi Tom,

We at Linaro are maintaining LLVM Arm/AArch64 buildbots and want a host
buildbot for testing of release branches.

Kindly share the steps to do this. Do we have to host separate builbots for
tracking release branches or is it possible to track multiple branches by
existing buildbots assuming traffic on release branches is less frequent?

On Tue, 2 Feb 2021 at 21:49, Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 2/2/21 1:23 AM, Diana Picus wrote:
> > Hi Tom,
> >
> > This sounds interesting! Would this also make it possible to
> automatically get the release binaries from the buildbots, as opposed to
> manually uploading to the FTP server?
> >
>
> Yes, this is something I would like to do.  I think you could pretty
> easily run
> the test-release.sh script on the bot.  The only issue is finding a way to
> securely upload the binaries.
>
> -Tom
>
> > Cheers,
> > Diana
> >
> > On Tue, 2 Feb 2021 at 01:46, Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org > wrote:
> >
> > Hi,
> >
> > I would like to improve the testing coverage in the release branch,
> so if you
> > are a buildbot owner and would like to enable your builder for the
> release branch,
> > let me know, and I can help get it enabled.
> >
> > Also, if you have any ideas for some more extensive testing that
> might be too
> > slow to run on the main branch, we may be able to enable it on the
> release
> > branch either running once per commit or once per tag.
> >
> > Thanks,
> > Tom
> >
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org 
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
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] RFC: AArch64 Linux Memory Tagging Support for LLDB

[Omair Javaid via lldb-dev]

Hi Jason,

I wanted to bring this to your attention that we are also working on
pointer authentication support. We have so far only done register context
changes to allow for enabling/disabling pointer authentication features and
read/write pauth Cmask/Dmask registers when available. I am currently
investigating unwinder support which means any further implementation from
my side will be an overlap with what you guys have done already. There can
also be design conflicts and I would really appreciate it if we can come on
some common ground regarding upstreaming of Apple's downstream pointer
authentication patches. We may collaborate and upstream unwinder support.

Thanks!

On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi David, thanks for the great writeup.  I hadn't been following the gdb
> MTE support.
>
> This all looks reasonable to me.  A few quick thoughts --
>
> The initial idea of commands like "memory showptrtag", "memory showtag",
> "memory checktag" - it might be better to put all of these under "memory
> tag ...", similar to how "breakpoint command ..." works.
>
> It makes sense to have lldb read/write the control pseudo-register as if
> it were a normal reg, in its own register grouping.  You mentioned that you
> had some thoughts about how to make it more readable to users - I know this
> is something Greg has been hoping to do / see done at some point, for
> control registers where we could annotate the registers a lot better.  I
> noticed that qemu for x86 provides exactly this kind of annotation
> information in its register target.xml definitions (v.
> lldb/test/API/functionalities/gdb_remote_client/TestRegDefinitionInParts.py
> ) but I don't THINK we do anything with these annotations today.  Not at
> all essential to this work, but just noting that this is something we all
> would like to see better support for.
>
> As for annotating the reason the program stopped on an MTE exception,
> Ismail was working on something similar in the past - although as you note,
> the really cool thing would be decoding the faulting instruction to
> understand what target register was responsible for the fault (and maybe
> even working back via the debug info to figure out what user-level variable
> it was??) to annotate it, which is something we're not doing anywhere right
> now.  There was a little proof-of-concept thing that Sean Callanan did
> years ago "frame diagnose" which would try to annotate to the user in
> high-level source terms why a fault happened, but I think it was using some
> string matching of x86 instructions to figure out what happened. :)
>
> We're overdue to upstream the PAC support for lldb that we're using, it's
> dependent on some other work being upstreamed that hasn't been done yet,
> but the general scheme involves querying the lldb-server / debugserver /
> corefile to get the number of bits used for virtual addressing, and then it
> just stomps on all the other high bits when trying to dereference values.
> If you do 'register read' of a function pointer, we show the actual value
> with PAC bits, then we strip the PAC bits off and if it resolves to a
> symbol, we print the stripped value and symbol that we're pointing to. It
> seems similar to what MTE will need -- if you have a variable pointing to
> heap using MTE, and you do `x/g var`, lldb should strip off the MTE bits
> before sending the address to read to lldb-server. The goal with the PAC UI
> design is to never hide the PAC details from the user, but to additionally
> show the PAC-less address when we're sure that it's an address in memory.
> Tougher to do that with MTE because we'll never be pointing to a symbol, it
> will be heap or stack.
>
> J
>
>
>
>
>
> > On Aug 10, 2020, at 3:41 AM, David Spickett via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > What follows is my proposal for supporting AArch64's memory tagging
> > extension in LLDB. I think the link in the first paragraph is a good
> > introduction if you haven't come across memory tagging before.
> >
> > I've also put the document in a Google Doc if that's easier for you to
> > read:
> https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
> > (please keep comments to this list though)
> >
> > Any and all comments welcome. Particularly I would like opinions on
> > the naming of the commands, as this extension is AArch64 specific but
> > the concept of memory tagging itself is not.
> > (I've added some people on Cc who might have particular interest)
> >
> > Thanks,
> > David Spickett.
> >
> > 
> >
> > # RFC: AArch64 Linux Memory Tagging Support for LLDB
> >
> > ## What is memory tagging?
> >
> > Memory tagging is an extension added in the Armv8.5-a architecture for
> AArch64.
> > It allows tagging pointers and storing those tags so that hardware can
> validate
> > that a pointer matches the memory address it is trying to access. These
> paired

[lldb-dev] [RFC] Support for AArch64/Arm64 scalable vector extension (SVE)

[Omair Javaid via lldb-dev]

Hi,

I am going to be starting work on implementing LLDB support for
AArch64/Arm64 scalable vector extension (SVE) in coming weeks. For a quick
walk through of SVE please read through this doc here:
https://www.kernel.org/doc/Documentation/arm64/sve.txt

In summary it allows hardware + kernel which support SVE to have variable
vector register lengths which can be configured as per system requirements
on per process or thread basis.

I have been informed that there might be some downstream patches and I
would like to collaborate with anyone who is willing to contribute their
completed or in-progress work.

I would also like to open a discussion on how we can implement variable
length registers in LLDB and what could be the consequences of those
changes.

Looking forward to hearing from the community.

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

[lldb-dev] LLDB remote tests via LIT and specifying threads check-lldb

[Omair Javaid via lldb-dev]

Hi

I am new to LIT and looking to run lldb testsuite in remote target
configuration via lit (ninja check-lldb). Also I am looking to
restrict check-lldb to run a specified number of threads at a time,
something similar to LLDB_TEST_THREADS=8 used with dotest.py.
Please share remote testing setup if someone has done it already.

Thanks!

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

[lldb-dev] LLDB testsuite failing to import lldb python module

[Omair Javaid via lldb-dev]

Hi,

I am trying to run lldb testsuite on arm hardware with lldb and
lldbserver binaries cross compiled on x86_64 builder.

I have lldb-server running on my arm hardware. Also i have lldb source
tree checkout and liblldb and lldb binaries places in lib and bin
folders respectively.

I am ablle to connect to my server by manualy running lldb and issuing
a platform connect command. However I am getting a python lldb module
import error like the one given below:

importerror: no module named lldb

I think i have some path issue or i am missing something while copying
lldb stuff from my builder.

Can someone track what I am doing wrong here?


Any help would be much appreciated.

here's how i am runing testsuite:

DOTEST_OPTS="--executable /home/omair/lldb/host/build/host/bin/lldb -A
arm -C gcc -s /home/omair/lldb/host/test/raspberryPi3-xenial
--skip-category lldb-mi -u CXXFLAGS -u CFLAGS --platform-name
remote-linux --platform-url connect://localhost:5432
--platform-working-dir /home/omair/lldb/armhf/tmp --env OS=Linux"
./dotest.py `echo $DOTEST_OPTS`



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

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

[Omair Javaid via lldb-dev]

Hi Will,

I dont understand REPL and thus the benefits it will have by making
change to architecture name. I would not recommend to drop any
information that we get from the host operating system.

LLDB maintains core information alongwith triple in ArchSpec, may be
you can parse triple to reflect correct core and use core instead of
architecture name where needed.

Kindly elaborate in a bit detail what are we getting out of this
change for more accurate comments.

Thanks!

On 26 January 2016 at 14:47, Pavel Labath  wrote:
> + Omair
>
> I don't really understand arm (sub)-architectures or REPL. The patch
> seems mostly harmless, but it also feels like a hack to me. A couple
> of questions:
> - why does this only pose a problem for REPL?
> - If I understand correctly, the problem is that someone is looking at
> the architecture string contained in the Triple, and not finding what
> it expects. Is that so? Could you point me to (some of) the places
> that do that.
>
> Omair, any thoughts on this?
>
> cheers,
> pl
>
>
> On 25 January 2016 at 18:55, Hans Wennborg  wrote:
>> This patch looks reasonable to me, but I don't know enough about LLDB
>> to actually review it.
>>
>> +Renato or Pavel maybe?
>>
>> On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
>>  wrote:
>>> Hi again, everyone
>>>
>>> I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
>>> merging it over is fairly straight-forward.
>>>
>>> Thanks in advance for your comments!
>>> - Will
>>>
 There is a small change that enables correct calculation of arm sub 
 architectures while using the REPL on arm-linux.  As you may of may or may 
 not know, linux appends ‘l’ to arm architecture versions to denote little 
 endian.  This sometimes interferes with the determination of the 
 architecture in the triple.  I experimented with adding sub architecture 
 entries for these within lldb, but I discovered a simpler (and less 
 invasive) method.  Because LLVM already knows how to handle some of these 
 cases (I have a patch submitted for review that enables v6l; v7l already 
 works), I am relying on llvm to clean it up.  The gist of it is that the 
 llvm constructor (when given a triple string) retains the provided string 
 unless an accessor mutates it.  Meanwhile, the accessors for the 
 components go through the aliasing and parsing logic.  This code detects 
 whether the sub-architecture that armv6l or armv7l aliases to is detected, 
 and re-sets the architecture in the triple.  This overwrites the 
 architecture that comes from linux, thus sanitizing it.

 Some kind of solution is required for the REPL to work on arm-linux.  
 Without it, the REPL crashes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev