[lldb-dev] [8.0.0 Release] One week to the branch

[Hans Wennborg via lldb-dev]

Hello everyone,

This is just a quick reminder that the upcoming release branch is
scheduled for creation one week from today, on Wednesday 16 January
2019.

The full schedule is available under "Upcoming Releases" in the right
column at https://llvm.org.

Please try to avoid committing disruptive changes just before or after
the branch.

As the branch is created, the trunk version will become 9.0.0.

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

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Stefan Gränitz via lldb-dev]

Hey Jonas that looks great! And what a nice way to do the review.

Two of the pages from "RESOURCES" are in the new docs now: Testing LLDB and The 
SB API Coding Rules
Will they be removed from the root page and/or do the others follow?

Added a few notes on escape characters to the review.

> The biggest issue is that the GDB to LLDB command map is totally unreadable 
> with the RST generated table. I spent a little time tweaking the CSS, but 
> this needs some attention. Worst case we'll have to have an HTML table here. 

GDB to LLDB map is one of  the most viewed pages in the docs right? I had a 
look and got the below result with a few CSS tweaks in the layout "debugger":

p, blockquote { margin-top: 0px; margin-bottom: 0px; }
tr.row-even { background: #eee; }
tr.row-odd td { font-family: monospace; padding-bottom: 15px; }
table.docutils { width: 100%; }

The last one sets full width on all tables. About columns having 
content-specific width, I am not sure. Might be interesting to see with a 50/50 
setting in all 's.
Maybe we could also get rid of the column headers? The prompts say it all :)




> On 8. Jan 2019, at 19:12, Jonas Devlieghere  wrote:
> 
> For those interested, I've uploaded the latest version of the generated HTML:
> 
> https://jonasdevlieghere.com/static/lldb/ 
> 
> 
> I'd have to double check but I think that almost everything was ported over. 
> The biggest issue is that the GDB to LLDB command map is totally unreadable 
> with the RST generated table. I spent a little time tweaking the CSS, but 
> this needs some attention. Worst case we'll have to have an HTML table here. 
> 
> Theme-wise I went with the one used by clang. I think it's the most readable 
> and I personally really like the local ToC. The disadvantage is that it 
> doesn't have a sidebar, so you have to navigate back to "contents" in the top 
> right corner.
> 
> The alternative is the LLVM theme where we can have Sphinx generate the 
> global ToC in the sidebar. When I tried this it was missing the section names 
> (e.g. "Goals & Status" as seen on the main page).  Another issue is that the 
> local ToC gets totally lost beneath it because everything doesn't fit on the 
> screen. Once I figure out how/if we can include the section names I'll 
> generate the site with the LLVM theme so people can compare and give their 
> opinion.
> 
> Cheers,
> Jonas
> 
> On Tue, Jan 8, 2019 at 9:31 AM Jonas Devlieghere  > wrote:
> 
> 
> On Tue, Jan 8, 2019 at 8:52 AM Stefan Gränitz via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> Hi Jonas, I think this is a great effort. Thanks!
> 
> My current reviews do some small updates on the build page. Hope this doesn't 
> get in conflict with your work?
> 
> Thanks for the heads up Stefan. This should be fine, I'll copy over your 
> change in the rst files. 
> 
> 
> Best
> Stefan
> 
>> On 6. Dec 2018, at 18:02, Jonas Devlieghere via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi everyone,
>> 
>> The current LLDB website is written in HTML which is hard to maintain. We 
>> have quite a bit of HTML code checked in which can make it hard to 
>> differentiate between documentation written by us and documentation 
>> generated by a tool. Furthermore I think text/RST files provide a lower 
>> barrier for new or casual contributors to fix or update.
>> 
>> In line with the other LLVM projects I propose generating the documentation 
>> with Sphix. I created a patch (https://reviews.llvm.org/D55376 
>> ) that adds a new target docs-lldb-html 
>> when -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to 
>> give an idea of what this would look like in-tree. Before continuing with 
>> this rather tedious work I'd like to get feedback form the community.
>> 
>> Initially I started with the theme used by Clang because it's a default 
>> theme and doesn't require configuration. If we want to keep the sidebar we 
>> could use the one used by LLD.
>> 
>> Please let me know what you think.
>> 
>> Thanks,
>> Jonas
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 

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

Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged

[Brian Cain via lldb-dev]

On Tue, Jan 8, 2019 at 11:25 PM Tom Stellard  wrote:

> On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote:
> > Can the ubuntu tarballs be published to the download site? They're not
> available yet.
> >
>
> These are up on the download site now.
>

Tom, releases.llvm.org only shows Windows and FreeBSD tarballs for 7.0.1
from what I can see.

Also, the front page of https://releases.llvm.org/ needs a new entry for
7.0.1 in the table under "Download".


>
> > On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev <
> cfe-...@lists.llvm.org > wrote:
> >
> > Ubuntu and SLES tarballs uploaded.  I haven't had a chance to make a
> SLES12 build yet, but I will try in the coming days.
> >
> > f7553a0d66092ca0bbe1eab2af405523a18bafba
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz
> > 41db01a3b216df4fc22fae9c44e248889f9a01ed
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> > caf149635742622a3a5b220146ff34f9202b8670
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
> > 5e2b33ac129b8471683dccaeb2818004eb5acea8
> clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz
> >
> >
> > On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers <
> release-test...@lists.llvm.org >
> wrote:
> >
> > On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers <
> release-test...@lists.llvm.org >
> wrote:
> > >
> > > I've tagged the 7.0.1 final release.  Testers may begin
> uploading binaries.
> >
> > Main test results on amd64-freebsd11 had 1 more Expected Pass
> compared to 7.0.1 rc3, and no more Passes With Retry:
> >
> > Expected Passes: 52445(7.0.1 rc3: 52444)
> > Passes With Retry  :   n/a(7.0.1 rc3: 1)
> > Expected Failures  :   232(7.0.1 rc3:   232)
> > Unsupported Tests  :  3687(7.0.1 rc3:  3687)
> > Unexpected Passes  : 1(7.0.1 rc3: 1)
> > Unexpected Failures:   491(7.0.1 rc3:   491)
> >
> > Test-suite results on amd64-freebsd11 did not change:
> >
> > Expected Passes:   903(7.0.1 rc3:   903)
> > Unexpected Failures: 3(7.0.1 rc3: 3)
> >
> > Test results on i386-freebsd11 had 1 more Expected Pass compared
> to 7.0.1 rc3, and 3 less Unexpected Failures:
> >
> > Expected Passes: 50254(7.0.1 rc3: 50253)
> > Passes With Retry  : 2(7.0.1 rc3:   n/a)
> > Expected Failures  :   226(7.0.1 rc3:   226)
> > Unsupported Tests  :  2502(7.0.1 rc3:  2502)
> > Unexpected Failures:   272(7.0.1 rc3:   275)
> >
> > The test-suite still doesn't build on i386-freebsd11, but that
> is a known issue.
> >
> > I have uploaded:
> >
> > SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) =
> 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407
> > SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) =
> 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36
> >
> > -Dimitry
> >
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org  release-test...@lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> >
> >
> >
> > --
> > -Brian
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> >
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> >
>
>

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

Re: [lldb-dev] [Reproducers] SBReproducer RFC

[Pavel Labath via lldb-dev]

On 08/01/2019 21:57, Jonas Devlieghere wrote:
Before I got around to coding this up I realized you can't take the 
address of constructors in C++, so the function address won't work as an 
identifier.




You gave up way too easily. :P

I realized that constructors are going to be tricky, but I didn't want 
to dive into those details until I knew if you liked the general idea. 
The most important thing to realize here is that for the identifier 
thingy to work, you don't actually need to use the address of that 
method/constructor as the identifier. It is sufficient to have something 
that can be deterministically computed from the function. Then you can 
use the address of *that* as the identifier.


I've created a very simple prototype , 
where I do just that. The way I handle constructors there is that I 
create a special class template (construct), whose instantiations are 
going to be unique for each constructor (I achieve that by making the 
class name and the constructor argument types the template parameters of 
that function). Then I can take the address of the static member 
function inside this class (&construct::doit), and 
use *that* as the ID.


As a nice side-effect, the "doit" method actually does invoke the 
constructor in question, so I can also use that in the replay code to 
treat constructors like any other method that returns an object.


I also do the same thing for (non-static) member functions via the 
"invoke" template, because even though it is possible to take the 
address of those, it is very hard to do anything else with the retrieved 
pointer. So the effect of this that in the rest of the code, I only have 
to work with free functions, as both constructors and member functions 
are converted into equivalent free functions. I haven't tried to handle 
destructors yet, but I don't think those should pose any problems that 
we haven't encountered already.


The example also show how you can use templates to automatically 
generate replay code for "simple" (i.e. those where you can 
(de)serialize each argument independently) functions, and then uses that 
to record/replay a very simple API.


You can see it in action like this:
$ g++ a.cc  # compile
$ ./a.out 2>/tmp/recording # generate the recording
SBFoo 47 42
Method 1 2
Static 10 11
$ cat /tmp/recording
0  # ID of the constructor
47 # constructor arg 1
42 # constructor arg 2
0x7ffd74d9a0f7 # constructor result
1  # id of SBFoo::Method
0x7ffd74d9a0f7 # this
1  # arg 1
2  # arg 2
2  # id of SBFoo::Static
10 # arg 1
11 # arg 2
$ ./a.out 1 < /tmp/recording # replay the recording
SBFoo 47 42
SBFoo 42 47
Method 1 2
Static 10 11

Note that when replaying the SBFoo constructor is called twice. This is 
because this code does not attempt to track the object instances in any 
way... it just creates a new one each time. This obviously needs to be 
fixed, but that's independent of the function ID issue.


hope you find that useful,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Reproducers] SBReproducer RFC

[Jonas Devlieghere via lldb-dev]

On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath  wrote:

> On 08/01/2019 21:57, Jonas Devlieghere wrote:
> > Before I got around to coding this up I realized you can't take the
> > address of constructors in C++, so the function address won't work as an
> > identifier.
> >
>
> You gave up way too easily. :P
>

I counted on you having something in mind, it sounded too obvious for you
to have missed.  ;-)

I realized that constructors are going to be tricky, but I didn't want
> to dive into those details until I knew if you liked the general idea.
> The most important thing to realize here is that for the identifier
> thingy to work, you don't actually need to use the address of that
> method/constructor as the identifier. It is sufficient to have something
> that can be deterministically computed from the function. Then you can
> use the address of *that* as the identifier.
>

I was thinking about that yesterday. I still feel like it would be better
to have this mapping all done at compile time. I was considering some kind
of constexpr hashing but that sounded overkill.


> I've created a very simple prototype ,
> where I do just that. The way I handle constructors there is that I
> create a special class template (construct), whose instantiations are
> going to be unique for each constructor (I achieve that by making the
> class name and the constructor argument types the template parameters of
> that function). Then I can take the address of the static member
> function inside this class (&construct::doit), and
> use *that* as the ID.


Clever!

As a nice side-effect, the "doit" method actually does invoke the
> constructor in question, so I can also use that in the replay code to
> treat constructors like any other method that returns an object.
>

This is really neat.


> I also do the same thing for (non-static) member functions via the
> "invoke" template, because even though it is possible to take the
> address of those, it is very hard to do anything else with the retrieved
> pointer. So the effect of this that in the rest of the code, I only have
> to work with free functions, as both constructors and member functions
> are converted into equivalent free functions. I haven't tried to handle
> destructors yet, but I don't think those should pose any problems that
> we haven't encountered already.
>
> The example also show how you can use templates to automatically
> generate replay code for "simple" (i.e. those where you can
> (de)serialize each argument independently) functions, and then uses that
> to record/replay a very simple API.
>
> You can see it in action like this:
> $ g++ a.cc  # compile
> $ ./a.out 2>/tmp/recording # generate the recording
> SBFoo 47 42
> Method 1 2
> Static 10 11
> $ cat /tmp/recording
> 0  # ID of the constructor
> 47 # constructor arg 1
> 42 # constructor arg 2
> 0x7ffd74d9a0f7 # constructor result
> 1  # id of SBFoo::Method
> 0x7ffd74d9a0f7 # this
> 1  # arg 1
> 2  # arg 2
> 2  # id of SBFoo::Static
> 10 # arg 1
> 11 # arg 2
> $ ./a.out 1 < /tmp/recording # replay the recording
> SBFoo 47 42
> SBFoo 42 47
> Method 1 2
> Static 10 11
>
> Note that when replaying the SBFoo constructor is called twice. This is
> because this code does not attempt to track the object instances in any
> way... it just creates a new one each time. This obviously needs to be
> fixed, but that's independent of the function ID issue.
>
> hope you find that useful,
> pl
>

Definitely, thank you for taking the time to code up a prototype.

Cheers,
Jonas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Reproducers] SBReproducer RFC

[Pavel Labath via lldb-dev]

On 09/01/2019 17:15, Jonas Devlieghere wrote:



On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath > wrote:


On 08/01/2019 21:57, Jonas Devlieghere wrote:
 > Before I got around to coding this up I realized you can't take the
 > address of constructors in C++, so the function address won't
work as an
 > identifier.
 >

You gave up way too easily. :P


I counted on you having something in mind, it sounded too obvious for 
you to have missed.  ;-)


I realized that constructors are going to be tricky, but I didn't want
to dive into those details until I knew if you liked the general idea.
The most important thing to realize here is that for the identifier
thingy to work, you don't actually need to use the address of that
method/constructor as the identifier. It is sufficient to have
something
that can be deterministically computed from the function. Then you can
use the address of *that* as the identifier.


I was thinking about that yesterday. I still feel like it would be 
better to have this mapping all done at compile time. I was considering 
some kind of constexpr hashing but that sounded overkill.




Well.. most of this is done through template meta-programming, which 
_is_ compile-time. And the fact that I have a use for the new 
construct/invoke functions I create this way means that even the space 
used by those isn't completely wasted (although I'm sure this could be 
made smaller with hard-coded IDs). The biggest impact of this I can 
think of is the increased number of dynamic relocations that need to be 
performed by the loader, as it introduces a bunch of function pointers 
floating around. But even that shouldn't too bad as we have plenty of 
other sources of dynamic relocs (currently about 4% of the size of 
liblldb and 10% of lldb-server).

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

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Jonas Devlieghere via lldb-dev]

On Wed, Jan 9, 2019 at 4:09 AM Stefan Gränitz  wrote:

> Hey Jonas that looks great! And what a nice way to do the review.
>
> Two of the pages from "RESOURCES" are in the new docs now: Testing LLDB
> and The SB API Coding Rules
> Will they be removed from the root page and/or do the others follow?
>
> Added a few notes on escape characters to the review.
>

Thanks!


> The biggest issue is that the GDB to LLDB command map is totally
> unreadable with the RST generated table. I spent a little time tweaking the
> CSS, but this needs some attention. Worst case we'll have to have an HTML
> table here.
>
>
> GDB to LLDB map is one of  the most viewed pages in the docs right? I had
> a look and got the below result with a few CSS tweaks in the layout
> "debugger":
>
> p, blockquote { margin-top: 0px; margin-bottom: 0px; }
> tr.row-even { background: #eee; }
> tr.row-odd td { font-family: monospace; padding-bottom: 15px; }
> table.docutils { width: 100%; }
>
>
Nice. I've added a custom class to these tables so we can limit these
changes to only this table. I think this looks pretty good (you might have
to clear your cache): https://jonasdevlieghere.com/static/lldb/use/map.html

I also managed to fix the column width, except for the first table. I'll
have another look soon.


> The last one sets full width on all tables. About columns having
> content-specific width, I am not sure. Might be interesting to see with a
> 50/50 setting in all 's.
> Maybe we could also get rid of the column headers? The prompts say it all
> :)
>
>
>
> On 8. Jan 2019, at 19:12, Jonas Devlieghere  wrote:
>
> For those interested, I've uploaded the latest version of the generated
> HTML:
>
> https://jonasdevlieghere.com/static/lldb/
>
> I'd have to double check but I think that almost everything was ported
> over. The biggest issue is that the GDB to LLDB command map is totally
> unreadable with the RST generated table. I spent a little time tweaking the
> CSS, but this needs some attention. Worst case we'll have to have an HTML
> table here.
>
> Theme-wise I went with the one used by clang. I think it's the most
> readable and I personally really like the local ToC. The disadvantage is
> that it doesn't have a sidebar, so you have to navigate back to "contents"
> in the top right corner.
>
> The alternative is the LLVM theme where we can have Sphinx generate the
> global ToC in the sidebar. When I tried this it was missing the section
> names (e.g. "Goals & Status" as seen on the main page).  Another issue is
> that the local ToC gets totally lost beneath it because everything doesn't
> fit on the screen. Once I figure out how/if we can include the section
> names I'll generate the site with the LLVM theme so people can compare and
> give their opinion.
>
> Cheers,
> Jonas
>
> On Tue, Jan 8, 2019 at 9:31 AM Jonas Devlieghere 
> wrote:
>
>>
>>
>> On Tue, Jan 8, 2019 at 8:52 AM Stefan Gränitz via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi Jonas, I think this is a great effort. Thanks!
>>>
>>> My current reviews do some small updates on the build page. Hope this
>>> doesn't get in conflict with your work?
>>>
>>
>> Thanks for the heads up Stefan. This should be fine, I'll copy over your
>> change in the rst files.
>>
>>
>>> Best
>>> Stefan
>>>
>>> On 6. Dec 2018, at 18:02, Jonas Devlieghere via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Hi everyone,
>>>
>>> The current LLDB website is written in HTML which is hard to maintain.
>>> We have quite a bit of HTML code checked in which can make it hard to
>>> differentiate between documentation written by us and documentation
>>> generated by a tool. Furthermore I think text/RST files provide a lower
>>> barrier for new or casual contributors to fix or update.
>>>
>>> In line with the other LLVM projects I propose generating the
>>> documentation with Sphix. I created a patch (
>>> https://reviews.llvm.org/D55376) that adds a new target docs-lldb-html
>>> when -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to
>>> give an idea of what this would look like in-tree. Before continuing with
>>> this rather tedious work I'd like to get feedback form the community.
>>>
>>> Initially I started with the theme used by Clang because it's a default
>>> theme and doesn't require configuration. If we want to keep the sidebar we
>>> could use the one used by LLD.
>>>
>>> Please let me know what you think.
>>>
>>> Thanks,
>>> Jonas
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Reproducers] SBReproducer RFC

[Jonas Devlieghere via lldb-dev]

On Wed, Jan 9, 2019 at 8:42 AM Pavel Labath  wrote:

> On 09/01/2019 17:15, Jonas Devlieghere wrote:
> >
> >
> > On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath  > > wrote:
> >
> > On 08/01/2019 21:57, Jonas Devlieghere wrote:
> >  > Before I got around to coding this up I realized you can't take
> the
> >  > address of constructors in C++, so the function address won't
> > work as an
> >  > identifier.
> >  >
> >
> > You gave up way too easily. :P
> >
> >
> > I counted on you having something in mind, it sounded too obvious for
> > you to have missed.  ;-)
> >
> > I realized that constructors are going to be tricky, but I didn't
> want
> > to dive into those details until I knew if you liked the general
> idea.
> > The most important thing to realize here is that for the identifier
> > thingy to work, you don't actually need to use the address of that
> > method/constructor as the identifier. It is sufficient to have
> > something
> > that can be deterministically computed from the function. Then you
> can
> > use the address of *that* as the identifier.
> >
> >
> > I was thinking about that yesterday. I still feel like it would be
> > better to have this mapping all done at compile time. I was considering
> > some kind of constexpr hashing but that sounded overkill.
> >
>
> Well.. most of this is done through template meta-programming, which
> _is_ compile-time. And the fact that I have a use for the new
> construct/invoke functions I create this way means that even the space
> used by those isn't completely wasted (although I'm sure this could be
> made smaller with hard-coded IDs). The biggest impact of this I can
> think of is the increased number of dynamic relocations that need to be
> performed by the loader, as it introduces a bunch of function pointers
> floating around. But even that shouldn't too bad as we have plenty of
> other sources of dynamic relocs (currently about 4% of the size of
> liblldb and 10% of lldb-server).
>

Yeah of course, it wasn't my intention to critique your approach. I was
talking specifically about the mapping (the std::map) in the prototype,
something I asked about earlier in the thread. FWIW I think this would be
an excellent trade-off is we don't need a tool to generate code for us. I'm
hopeful that we can have the gross of the deserialization code generated
this way, most of the "special" cases are still pretty similar and dealing
with basic types. Anyway, that should become clear later today as I
integrate this into the lldb prototype.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [monorepo] Downstream repo import tool available

[David Greene via lldb-dev]

I've created a tool that takes a downstream repository and imports it
into the monorepo such that trees appear under a given subdirectory in
the monorepo:

https://github.com/jyknight/llvm-git-migration/pull/6

This is useful for downstream users who have repositories that make
heavy use of LLVM libraries and logically operate as extensions of the
LLVM ecosystem.

By default, downstream repo commits are rewritten such that the *only*
blobs in their trees are from the downstream repo.  Thus checking out
such commits will populate the workare with *only* the subdirectory
containing the imported repository artifacts.  A post-import merge with
an upstream monorepo commit will unify the trees and result in checkouts
that populate the workarea with monorepo and downstream repo artifacts.
There are some experimental options to rewrite downstream repo trees
alongside an existing monorepo tree but they are not well-tested.

There is no effort to interleave commits from the downstream repo with
commits from other imported downstream repos, or downstream branches of
the monorepo.  That would be a separate tool, I think, and would require
some fundamental reworking of fast_filter_branch.py that I didn't want
to tackle at this point.  If such downstream repos and/or branches have
commits ordered via submodule updates in some "umbrella" repository,
then zip-downstream-fork.py can be used to import and interleave them:

https://github.com/jyknight/llvm-git-migration/pull/2

Hopefully others will find these tools useful.

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

[lldb-dev] RFC: Simplifying SymbolFile interface

[Zachary Turner via lldb-dev]

The Native PDB symbol file plugin I think is mostly complete.  It's at
least almost as good as the old Windows-only PDB plugin in 90% of ways,
while actually being significantly better in other ways (for example, there
was a test that took over 2 minutes to run with the Windows-only PDB
plugin, which now takes about 2 seconds to run with the native PDB plugin.

While implementing this, I ran into several things that made my life quite
difficult, and only later found out that I could have saved myself a lot of
headache and time if the SymbolFile interface had been a little simpler and
easier to understand.

Specifically, I'd like to remove the heavy use of SymbolContext in the
SymbolFile / SymbolVendor interface and replace it with more narrow and
targeted parameter lists.

Consider the case of someone calling FindTypes.  In theory, today they can
fill out any combination of Target, Module, Function, Block, CompileUnit,
LineEntry, and Symbol.  That's 2^7 different possible ways the function can
be called.  While obviously not all of these combinations make sense, the
fact is that it greatly increases the API surface, which is bad for test
coverage, bad for ease of understanding, bad for usability, and leads to a
lot of dead code.

For a person implementing this function for the first time, and who may not
know all the details about how the rest of LLDB works, this is quite
daunting because there's an inherent desire to implement the function
faithfully "just in case", since they don't know all of the different ways
the function might be called.

This results in wasted time on the developer's part, because they end up
implementing a bunch of functionality that is essentially dead code.

We can certainly document for every single function "The implementor should
be prepared to handle the case of fields X, Y, and Z being set, and handle
it in such and such way", but I think it's easier to just change the
interface to be more clear in the first place.


Here are the cases I identified, and a proposal for how I could change the
interface.

1) SymbolFile::ParseTypes(SymbolContext&)
  * In the entire codebase, this is only called with a CompileUnit set.  We
should change this to be ParseTypesForCompileUnit(CompileUnit&) so that the
interface is self-documenting.  A patch with this change is here [
https://reviews.llvm.org/D56462]

2) SymbolFile::ParseDeclsForContext(CompilerDeclContext)
  * This is intended to only be used for parsing variables in a block.  But
should it be recursive?  It's impossible to tell from the function name, so
callers can't use it correctly and implementors can't implement it
correctly.  I spent 4 days trying to implement a generic version of this
function for the NativePDB plugin only to find out that I only actually
cared about block variables.  I would propose changing this to
ParseVariableDeclsForBlock(Block&).

3) These functions:
 * ParseCompileUnitLanguage(SymbolContext&)
 * ParseCompileUnitFunctions(SymbolContext&)
 * ParseCompileUnitLineTable(SymbolContext&)
 * ParseCompileUnitDebugMacros(SymbolContext&)
 * ParseCompileUnitSupportFiles(SymbolContext&)

are only for CompileUnits (as the name implies.  I propose changing the
parameter from a SymbolContext& to a CompileUnit&.

4) SymbolFile::ParseFunctionBlocks(SymbolContext&)
 * This is intended to be used when the SymbolContexts m_function member is
set.  I propose changing this to SymbolFile::ParseFunctionBlocks(Function&).

5) SymbolFile::ParseVariablesForContext(CompilerDeclContext)
* This function is only called with the the Context being a CompileUnit,
Function, and Block.  But does it need to be recursive?  For a Function and
Block it seems to be assumed to be recursive, and for a CompileUnit it
seems to be assumed to not be recursive.  For the former case, it's not
actually clear how this function differs from ParseGlobalVariables, and for
the latter case I would propose changing this to
ParseImmedateVariablesForBlock(Block&).

6) SymbolFile::FindTypes(SymbolContext&).
* This function is only called with the m_module field set, and since a
SymbolFile is already tied to a module anyway, the parameter appears
unnecessary.  I propose changing this to SymbolFile::FindAllTypes()

7) SymbolFile::FindNamespace(SymbolContext&, ConstString, DeclContext*) is
only called with default-constructed (i.e. null) SymbolContexts, making the
first parameter unnecessary.  I propose changing this to
FindNamespace(ConstString, DeclContext*)


8)   Module::FindTypes(SymbolContext &, ConstString, bool , size_t ,
DenseSet &, TypeList&):

* After the change in #6, we can propagate this change upwards for greater
benefit.  The first parameter in Module::FindTypes(SymbolContext&, ...) now
becomes unnecessary (and in fact, it was kind of unnecessary to begin with
since in every case, the SymbolContext actually just had a single member
set, which was equal to the this pointer of the Module from which this
function was called).  So I propose deleting thi

Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/09/2019 05:03 AM, Brian Cain wrote:
> 
> 
> On Tue, Jan 8, 2019 at 11:25 PM Tom Stellard  > wrote:
> 
> On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote:
> > Can the ubuntu tarballs be published to the download site? They're not 
> available yet.
> >
> 
> These are up on the download site now.
> 
> 
> Tom, releases.llvm.org  only shows Windows and 
> FreeBSD tarballs for 7.0.1 from what I can see.
> 

I forgot to add the links, they are up now.

> Also, the front page of https://releases.llvm.org/ needs a new entry for 
> 7.0.1 in the table under "Download".
>  

This has been fixed too.

-Tom
> 
> 
> > On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Ubuntu and SLES tarballs uploaded.  I haven't had a chance to make 
> a SLES12 build yet, but I will try in the coming days.
> >
> > f7553a0d66092ca0bbe1eab2af405523a18bafba  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz
> > 41db01a3b216df4fc22fae9c44e248889f9a01ed  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> > caf149635742622a3a5b220146ff34f9202b8670  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
> > 5e2b33ac129b8471683dccaeb2818004eb5acea8  
> clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz
> >
> >
> > On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers 
> mailto:release-test...@lists.llvm.org> 
>  >> wrote:
> >
> > On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers 
> mailto:release-test...@lists.llvm.org> 
>  >> wrote:
> > >
> > > I've tagged the 7.0.1 final release.  Testers may begin 
> uploading binaries.
> >
> > Main test results on amd64-freebsd11 had 1 more Expected Pass 
> compared to 7.0.1 rc3, and no more Passes With Retry:
> >
> > Expected Passes: 52445(7.0.1 rc3: 52444)
> > Passes With Retry  :   n/a(7.0.1 rc3: 1)
> > Expected Failures  :   232(7.0.1 rc3:   232)
> > Unsupported Tests  :  3687(7.0.1 rc3:  3687)
> > Unexpected Passes  : 1(7.0.1 rc3: 1)
> > Unexpected Failures:   491(7.0.1 rc3:   491)
> >
> > Test-suite results on amd64-freebsd11 did not change:
> >
> > Expected Passes:   903(7.0.1 rc3:   903)
> > Unexpected Failures: 3(7.0.1 rc3: 3)
> >
> > Test results on i386-freebsd11 had 1 more Expected Pass 
> compared to 7.0.1 rc3, and 3 less Unexpected Failures:
> >
> > Expected Passes: 50254(7.0.1 rc3: 50253)
> > Passes With Retry  : 2(7.0.1 rc3:   n/a)
> > Expected Failures  :   226(7.0.1 rc3:   226)
> > Unsupported Tests  :  2502(7.0.1 rc3:  2502)
> > Unexpected Failures:   272(7.0.1 rc3:   275)
> >
> > The test-suite still doesn't build on i386-freebsd11, but that 
> is a known issue.
> >
> > I have uploaded:
> >
> > SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = 
> 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407
> > SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = 
> 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36
> >
> > -Dimitry
> >
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org 
>  
>  >
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> >
> >
> >
> > --
> > -Brian
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org  
> >
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> >
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> >
> 
> 
> 
> -- 
> -Brian

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