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

[Pavel Labath via lldb-dev]

On 07/01/2019 22:45, Frédéric Riss wrote:



On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:


On 07/01/2019 19:26, Jonas Devlieghere wrote:
On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > wrote:

   I've been thinking about how could this be done better, and the best
   (though not ideal) way I came up with is using the functions 
address as

   the key. That's guaranteed to be unique everywhere. Of course, you
   cannot serialize that to a file, but since you already have a central
   place where you list all intercepted functions (to register their
   replayers), that place can be also used to assign unique integer 
IDs to

   these functions. So then the idea would be that the SB_RECORD macro
   takes the address of the current function, that gets converted to 
an ID

   in the lookup table, and the ID gets serialized.
It sound like you would generate the indices at run-time. How would 
that work with regards to the the reverse mapping?
In the current implementation, SBReplayer::Init contains a list of all 
intercepted methods, right? Each of the SB_REGISTER calls takes two 
arguments: The method name, and the replay implementation.


I would change that so that this macro takes three arguments:
- the function address (the "runtime" ID)
- an integer (the "serialized" ID)
- the replay implementation

This creates a link between the function address and the serialized 
ID. So when, during capture, a method calls SB_RECORD_ENTRY and passes 
in the function address, that address can be looked up and translated 
to an ID for serialization.


The only thing that would need to be changed is to have 
SBReplayer::Init execute during record too (which probably means it 
shouldn't be called SBReplayer, but whatever..), so that the ID 
mapping is also available when capturing.


Does that make sense?


I think I understand what you’re explaining, and the mapping side of 
things makes sense. But I’m concerned about the size and complexity of 
the SB_RECORD macro that will need to be written. IIUC, those would need 
to take the address of the current function and the prototype, which is 
a lot of cumbersome text to type. It seems like having a specialized 
tool to generate those would be nice, but once you have a tool you also 
don’t need all this complexity, do you?


Fred



Yes, if the tool generates the IDs for you and checks that the macro 
invocations are correct, then you don't need the function prototype. 
However, that tool also doesn't come for free: Somebody has to write it, 
and it adds complexity in the form of an extra step in the build process.


My point is that this extended macro could provide all the 
error-checking benefits of this tool. It's a tradeoff, of course, and 
the cost here is a more complex macro invocation. I think the choice 
here is mostly down to personal preference of whoever implements this. 
However, if I was implementing this, I'd go for an extended macro, 
because I don't find the extra macro complexity to be too much. For 
example, this should be the macro invocation for 
SBData::SetDataFromDoubleArray:


SB_RECORD(bool, SBData, SetDataFromDoubleArray, (double *, size_t),
array, array_len);

It's a bit long, but it's not that hard to type, and all of this 
information should be present on the previous line, where 
SBData::SetDataFromDoubleArray is defined (I deliberately made the macro 
argument order match the function definition syntax).


And this approach can be further tweaked. For instance, if we're willing 
to take the hit of having "weird" function definitions, then we can 
avoid the repetition altogether, and make the macro define the function too:


SB_METHOD2(bool, SBData, SetDataFromDoubleArray, double *, array,
size_t, array_len, {
  // Method body
})

This would also enable you to automatically capture method return value 
for the "object" results.


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

[Pavel Labath via lldb-dev]

On 07/01/2019 22:13, Jonas Devlieghere wrote:



On Mon, Jan 7, 2019 at 3:52 AM Tamas Berghammer > wrote:


One problem is when the behavior of LLDB is not deterministic for
whatever reason (e.g. multi threading, unordered maps, etc...). Lets
take SBModule::FindSymbols() what returns an SBSymbolContextList
without any specific order (haven't checked the implementation but I
would consider a random order to be valid). If a user calls this
function, then iterates through the elements to find an index `I`,
calls `GetContextAtIndex(I)` and pass the result into a subsequent
function then what will we do. Will we capture what did
`GetContextAtIndex(I)` returned in the trace and use that value or
will we capture the value of `I`, call `GetContextAtIndex(I)` during
reproduction and use that value. Doing the first would be correct in
this case but would mean we don't call `GetContextAtIndex(I)` while
doing the second case would mean we call `GetContextAtIndex(I)` with
a wrong index if the order in SBSymbolContextList is non
deterministic. In this case as we know that GetContextAtIndex is
just an accessor into a vector the first option is the correct one
but I can imagine cases where this is not the case (e.g. if
GetContextAtIndex would have some useful side effect).


Indeed, in this scenario we would replay the call with the same `I` 
resulting in an incorrect value. I think the only solution is fixing the 
non-derterminism. This should be straightforward for lists (some kind of 
sensible ordering), but maybe there are other issues I'm not aware of.


For this, I think we should adopt the same rules that llvm has for 
nondeterminism: returning entries in an unspecified order is fine as 
long as that order is always the same for the given set of inputs. So, 
using unordered maps is fine as long as it doesn't use any 
runtime-dependent values (pointers), or this nondeterminism is removed 
(explicit sort) before letting the values out.


This way, when you're debugging something, and your replay doesn't work 
because of nondeterminism, you fix the nodeterministic bug. It may not 
have been the bug you set out to fix, but you still reduce the overall 
number of bugs.




Other interesting question is what to do with functions taking raw
binary data in the form of a pointer + size (e.g. SBData::SetData).
I think we will have to annotate these APIs to make the reproducer
system aware of the amount of data they have to capture and then
allocate these buffers with the correct lifetime during replay. I am
not sure what would be the best way to attach these annotations but
I think we might need a fairly generic framework because I won't be
surprised if there are more situation when we have to add
annotations to the API. I slightly related question is if a function
returns a pointer to a raw buffer (e.g. const char* or void*) then
do we have to capture the content of it or the pointer for it and in
either case what is the lifetime of the buffer returned (e.g.
SBError::GetCString() returns a buffer what goes out of scope when
the SBError goes out of scope).


This a good concern and not something I had a good solution for at this 
point. For const char* string we work around this by serializing the 
actual string. Obviously that won't always work. Also we have the void* 
batons for callsback, which is another tricky thing that wouldn't be 
supported. I'm wondering if we can get away with ignoring these at first 
(maybe printing something in the replay logic that warns the user that 
the reproducer contains an unsupported function?).


Overall, I think we should leave some space to enable hand-written 
record/replay logic for the tricky cases. Batons will be one of those 
cases, but I don't think they're unsolvable. The only thing we can do 
with a user-specified void* baton is pass it back to the user callback. 
But we're not going to that since we don't have the code for the 
callback anyway. Nor do we need to do that since we're not interested in 
what happens outside of SB boundary.


For this, I think the right solution is to replay the *effects* of the 
call to the user callback by re-executing the SB calls it made, which 
can be recorded as usual, when they cross the SB boundary.




Additionally I am pretty sure we have at least some functions
returning various indices what require remapping other then the
pointers either because they are just indexing into a data structure
with undefined internal order or they referencing some other
resource. Just by randomly browsing some of the SB APIs I found for
example SBHostOS::ThreadCreate what returns the pid/tid for the
newly created thread what will have to be remapped (it also takes a
function as an argument what is a problem as well). Because of this
I am not sure if we can get aw

[lldb-dev] [CMake] LLDB_TEST_(C/CXX)_COMPILER in patches for standalone and testing

[Stefan Gränitz via lldb-dev]

Hi all

I put a number of patches for review that are related to LLDB standalone builds 
and testing. They mostly clean up things that confused me while investigating 
the mysterious problem with the cxx target dependency [1][2].

One of the changes [4] has relevant effects on CMake parameters: it deprecates 
LLDB_TEST_C/CXX_COMPILER in favor of a unified LLDB_TEST_COMPILER (for details 
on the change itself, let's discuss in the review). 
As this may affect build bot configurations etc., the old parameters are only 
marked deprecated for now and will continue to work. I imagined to phase them 
out until the 8.0 release. What do you think?

The other related reviews are linked below.

Best
Stefan

--

[1] https://bugs.llvm.org/show_bug.cgi?id=40201 

[2] https://reviews.llvm.org/D56399 
[3] https://reviews.llvm.org/D56400 
[4] https://reviews.llvm.org/D56440 
[5] https://reviews.llvm.org/D56443 

___
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

[Frédéric Riss via lldb-dev]

> On Jan 8, 2019, at 1:25 AM, Pavel Labath  wrote:
> 
> On 07/01/2019 22:45, Frédéric Riss wrote:
>>> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> On 07/01/2019 19:26, Jonas Devlieghere wrote:
 On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath >>> > wrote:
I've been thinking about how could this be done better, and the best
(though not ideal) way I came up with is using the functions address as
the key. That's guaranteed to be unique everywhere. Of course, you
cannot serialize that to a file, but since you already have a central
place where you list all intercepted functions (to register their
replayers), that place can be also used to assign unique integer IDs to
these functions. So then the idea would be that the SB_RECORD macro
takes the address of the current function, that gets converted to an ID
in the lookup table, and the ID gets serialized.
 It sound like you would generate the indices at run-time. How would that 
 work with regards to the the reverse mapping?
>>> In the current implementation, SBReplayer::Init contains a list of all 
>>> intercepted methods, right? Each of the SB_REGISTER calls takes two 
>>> arguments: The method name, and the replay implementation.
>>> 
>>> I would change that so that this macro takes three arguments:
>>> - the function address (the "runtime" ID)
>>> - an integer (the "serialized" ID)
>>> - the replay implementation
>>> 
>>> This creates a link between the function address and the serialized ID. So 
>>> when, during capture, a method calls SB_RECORD_ENTRY and passes in the 
>>> function address, that address can be looked up and translated to an ID for 
>>> serialization.
>>> 
>>> The only thing that would need to be changed is to have SBReplayer::Init 
>>> execute during record too (which probably means it shouldn't be called 
>>> SBReplayer, but whatever..), so that the ID mapping is also available when 
>>> capturing.
>>> 
>>> Does that make sense?
>> I think I understand what you’re explaining, and the mapping side of things 
>> makes sense. But I’m concerned about the size and complexity of the 
>> SB_RECORD macro that will need to be written. IIUC, those would need to take 
>> the address of the current function and the prototype, which is a lot of 
>> cumbersome text to type. It seems like having a specialized tool to generate 
>> those would be nice, but once you have a tool you also don’t need all this 
>> complexity, do you?
>> Fred
> 
> Yes, if the tool generates the IDs for you and checks that the macro 
> invocations are correct, then you don't need the function prototype. However, 
> that tool also doesn't come for free: Somebody has to write it, and it adds 
> complexity in the form of an extra step in the build process.

Definitely agreed, the complexity has to be somewhere.

> My point is that this extended macro could provide all the error-checking 
> benefits of this tool. It's a tradeoff, of course, and the cost here is a 
> more complex macro invocation. I think the choice here is mostly down to 
> personal preference of whoever implements this. However, if I was 
> implementing this, I'd go for an extended macro, because I don't find the 
> extra macro complexity to be too much. For example, this should be the macro 
> invocation for SBData::SetDataFromDoubleArray:
> 
> SB_RECORD(bool, SBData, SetDataFromDoubleArray, (double *, size_t),
>array, array_len);

Yeah, this doesn’t seem so bad. For some reason I imagined it much more 
verbose. Note that a verification tool that checks that every SB method is 
instrumented correctly would still be nice (but it can come as a follow-up).

> It's a bit long, but it's not that hard to type, and all of this information 
> should be present on the previous line, where SBData::SetDataFromDoubleArray 
> is defined (I deliberately made the macro argument order match the function 
> definition syntax).
> 
> And this approach can be further tweaked. For instance, if we're willing to 
> take the hit of having "weird" function definitions, then we can avoid the 
> repetition altogether, and make the macro define the function too:
> 
> SB_METHOD2(bool, SBData, SetDataFromDoubleArray, double *, array,
>size_t, array_len, {
>  // Method body
> })

I personally don’t like this.

Fred

> This would also enable you to automatically capture method return value for 
> the "object" results.
> 
> pl

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

[lldb-dev] [Bug 40201] regression: can't build from source: The dependency target "cxx" of target "check-all" does not exist

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=40201

Stefan Gränitz  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #11 from Stefan Gränitz  ---
Changed ticket resolution to 'FIXED' and added minimal documentation update for
the 'BUILDING LLDB ON MAC OS X' section in the review:
https://reviews.llvm.org/D56399#change-ZmD6p3Up3VT9

-- 
You are receiving this mail because:
You are the assignee for the bug.___
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]

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?

Best
Stefan

> On 6. Dec 2018, at 18:02, Jonas Devlieghere via lldb-dev 
>  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

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

[Jonas Devlieghere via lldb-dev]

On Tue, Jan 8, 2019 at 8:27 AM Frédéric Riss  wrote:

>
>
> > On Jan 8, 2019, at 1:25 AM, Pavel Labath  wrote:
> >
> > On 07/01/2019 22:45, Frédéric Riss wrote:
> >>> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org > wrote:
> >>>
> >>> On 07/01/2019 19:26, Jonas Devlieghere wrote:
>  On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath  pa...@labath.sk>> wrote:
> I've been thinking about how could this be done better, and the
> best
> (though not ideal) way I came up with is using the functions
> address as
> the key. That's guaranteed to be unique everywhere. Of course, you
> cannot serialize that to a file, but since you already have a
> central
> place where you list all intercepted functions (to register their
> replayers), that place can be also used to assign unique integer
> IDs to
> these functions. So then the idea would be that the SB_RECORD macro
> takes the address of the current function, that gets converted to
> an ID
> in the lookup table, and the ID gets serialized.
>  It sound like you would generate the indices at run-time. How would
> that work with regards to the the reverse mapping?
> >>> In the current implementation, SBReplayer::Init contains a list of all
> intercepted methods, right? Each of the SB_REGISTER calls takes two
> arguments: The method name, and the replay implementation.
> >>>
> >>> I would change that so that this macro takes three arguments:
> >>> - the function address (the "runtime" ID)
> >>> - an integer (the "serialized" ID)
> >>> - the replay implementation
> >>>
> >>> This creates a link between the function address and the serialized
> ID. So when, during capture, a method calls SB_RECORD_ENTRY and passes in
> the function address, that address can be looked up and translated to an ID
> for serialization.
> >>>
> >>> The only thing that would need to be changed is to have
> SBReplayer::Init execute during record too (which probably means it
> shouldn't be called SBReplayer, but whatever..), so that the ID mapping is
> also available when capturing.
> >>>
> >>> Does that make sense?
> >> I think I understand what you’re explaining, and the mapping side of
> things makes sense. But I’m concerned about the size and complexity of the
> SB_RECORD macro that will need to be written. IIUC, those would need to
> take the address of the current function and the prototype, which is a lot
> of cumbersome text to type. It seems like having a specialized tool to
> generate those would be nice, but once you have a tool you also don’t need
> all this complexity, do you?
> >> Fred
> >
> > Yes, if the tool generates the IDs for you and checks that the macro
> invocations are correct, then you don't need the function prototype.
> However, that tool also doesn't come for free: Somebody has to write it,
> and it adds complexity in the form of an extra step in the build process.
>
> Definitely agreed, the complexity has to be somewhere.
>
> > My point is that this extended macro could provide all the
> error-checking benefits of this tool. It's a tradeoff, of course, and the
> cost here is a more complex macro invocation. I think the choice here is
> mostly down to personal preference of whoever implements this. However, if
> I was implementing this, I'd go for an extended macro, because I don't find
> the extra macro complexity to be too much. For example, this should be the
> macro invocation for SBData::SetDataFromDoubleArray:
> >
> > SB_RECORD(bool, SBData, SetDataFromDoubleArray, (double *, size_t),
> >array, array_len);
>
> Yeah, this doesn’t seem so bad. For some reason I imagined it much more
> verbose. Note that a verification tool that checks that every SB method is
> instrumented correctly would still be nice (but it can come as a follow-up).
>

It sounds like this should work but we should try it out to be sure. I'll
rework the prototype to use the function address and update the thread with
my findings. I also like the idea of using templates to generate the
parsers so I'll try that as well.


> > It's a bit long, but it's not that hard to type, and all of this
> information should be present on the previous line, where
> SBData::SetDataFromDoubleArray is defined (I deliberately made the macro
> argument order match the function definition syntax).
> >
> > And this approach can be further tweaked. For instance, if we're willing
> to take the hit of having "weird" function definitions, then we can avoid
> the repetition altogether, and make the macro define the function too:
> >
> > SB_METHOD2(bool, SBData, SetDataFromDoubleArray, double *, array,
> >size_t, array_len, {
> >  // Method body
> > })
>
> I personally don’t like this.
>
> Fred
>
> > This would also enable you to automatically capture method return value
> for the "object" results.
> >
> > pl
>
>
_

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

[Jonas Devlieghere via lldb-dev]

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] [RFC] Using Sphinx to generate documentation

[Jonas Devlieghere via lldb-dev]

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]

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.

On Tue, Jan 8, 2019 at 9:28 AM Jonas Devlieghere 
wrote:

> On Tue, Jan 8, 2019 at 8:27 AM Frédéric Riss  wrote:
>
>>
>>
>> > On Jan 8, 2019, at 1:25 AM, Pavel Labath  wrote:
>> >
>> > On 07/01/2019 22:45, Frédéric Riss wrote:
>> >>> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev <
>> lldb-dev@lists.llvm.org > wrote:
>> >>>
>> >>> On 07/01/2019 19:26, Jonas Devlieghere wrote:
>>  On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > > wrote:
>> I've been thinking about how could this be done better, and the
>> best
>> (though not ideal) way I came up with is using the functions
>> address as
>> the key. That's guaranteed to be unique everywhere. Of course, you
>> cannot serialize that to a file, but since you already have a
>> central
>> place where you list all intercepted functions (to register their
>> replayers), that place can be also used to assign unique integer
>> IDs to
>> these functions. So then the idea would be that the SB_RECORD
>> macro
>> takes the address of the current function, that gets converted to
>> an ID
>> in the lookup table, and the ID gets serialized.
>>  It sound like you would generate the indices at run-time. How would
>> that work with regards to the the reverse mapping?
>> >>> In the current implementation, SBReplayer::Init contains a list of
>> all intercepted methods, right? Each of the SB_REGISTER calls takes two
>> arguments: The method name, and the replay implementation.
>> >>>
>> >>> I would change that so that this macro takes three arguments:
>> >>> - the function address (the "runtime" ID)
>> >>> - an integer (the "serialized" ID)
>> >>> - the replay implementation
>> >>>
>> >>> This creates a link between the function address and the serialized
>> ID. So when, during capture, a method calls SB_RECORD_ENTRY and passes in
>> the function address, that address can be looked up and translated to an ID
>> for serialization.
>> >>>
>> >>> The only thing that would need to be changed is to have
>> SBReplayer::Init execute during record too (which probably means it
>> shouldn't be called SBReplayer, but whatever..), so that the ID mapping is
>> also available when capturing.
>> >>>
>> >>> Does that make sense?
>> >> I think I understand what you’re explaining, and the mapping side of
>> things makes sense. But I’m concerned about the size and complexity of the
>> SB_RECORD macro that will need to be written. IIUC, those would need to
>> take the address of the current function and the prototype, which is a lot
>> of cumbersome text to type. It seems like having a specialized tool to
>> generate those would be nice, but once you have a tool you also don’t need
>> all this complexity, do you?
>> >> Fred
>> >
>> > Yes, if the tool generates the IDs for you and checks that the macro
>> invocations are correct, then you don't need the function prototype.
>> However, that tool also doesn't come for free: Somebody has to write it,
>> and it adds complexity in the form of an extra step in the build process.
>>
>> Definitely agreed, the complexity has to be somewhere.
>>
>> > My point is that this extended macro could provide all the
>> error-checking benefits of this tool. It's a tradeoff, of course, and the
>> cost here is a more complex macro invocation. I think the choice here is
>> mostly down to personal preference of whoever implements this. However, if
>> I was implementing this, I'd go for an extended macro, because I don't find
>> the extra macro complexity to be too much. For example, this should be the
>> macro invocation for SBData::SetDataFromDoubleArray:
>> >
>> > SB_RECORD(bool, SBData, SetDataFromDoubleArray, (double *, size_t),
>> >array, array_len);
>>
>> Yeah, this doesn’t seem so bad. For some reason I imagined it much more
>> verbose. Note that a verification tool that checks that every SB method is
>> instrumented correctly would still be nice (but it can come as a follow-up).
>>
>
> It sounds like this should work but we should try it out to be sure. I'll
> rework the prototype to use the function address and update the thread with
> my findings. I also like the idea of using templates to generate the
> parsers so I'll try that as well.
>
>
>> > It's a bit long, but it's not that hard to type, and all of this
>> information should be present on the previous line, where
>> SBData::SetDataFromDoubleArray is defined (I deliberately made the macro
>> argument order match the function definition syntax).
>> >
>> > And this approach can be further tweaked. For instance, if we're
>> willing to take the hit of having "weird" function definitions, then we can
>> avoid the repetition altogether, and make the macro define the function too:
>> >
>> > SB_ME

Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

[Joel E. Denny via lldb-dev]

On Mon, Jan 7, 2019 at 9:08 PM Joel E. Denny  wrote:

> On Mon, Jan 7, 2019 at 11:39 AM Adrian Prantl  wrote:
>
>>
>>
>> On Jan 7, 2019, at 8:28 AM, Joel E. Denny via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano 
>> wrote:
>>
>>> On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev
>>>  wrote:
>>> >
>>> > On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss  wrote:
>>> >>
>>> >>
>>> >>
>>> >> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny 
>>> wrote:
>>> >> >
>>> >> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss 
>>> wrote:
>>> >> > -llvm-dev + lldb-dev for the lldv test failures.
>>> >> >
>>> >> >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny 
>>> wrote:
>>> >> >>
>>> >> >> All,
>>> >> >>
>>> >> >> Thanks for the replies.  Kuba: For LLDB, when were things expected
>>> to have improved?  It's possible things improved for me at some point, but
>>> this isn't something I've found time to track carefully, and I still see
>>> problems.
>>> >> >>
>>> >> >> I ran check-all a couple of times last night at r350238, which I
>>> pulled yesterday.  Here are the results:
>>> >> >>
>>> >> >> ```
>>> >> >> 
>>> >> >> Testing Time: 5043.24s
>>> >> >> 
>>> >> >> Unexpected Passing Tests (2):
>>> >> >> lldb-Suite :: functionalities/asan/TestMemoryHistory.py
>>> >> >> lldb-Suite :: functionalities/asan/TestReportData.py
>>> >> >>
>>> >> >> 
>>> >> >> Failing Tests (54):
>>> >> >> Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp
>>> >> >> Clang :: Modules/ExtDebugInfo.cpp
>>> >> >> Clang :: Modules/using-directive-redecl.cpp
>>> >> >> Clang :: Modules/using-directive.cpp
>>> >> >> Clang :: PCH/chain-late-anonymous-namespace.cpp
>>> >> >> Clang :: PCH/cxx-namespaces.cpp
>>> >> >> Clang :: PCH/namespaces.cpp
>>> >> >> LLDB :: ExecControl/StopHook/stop-hook-threads.test
>>> >> >> LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/
>>> use_tls_dynamic.cc
>>> >> >> LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/
>>> use_tls_dynamic.cc
>>> >> >> MemorySanitizer-X86_64 :: dtls_test.c
>>> >> >> MemorySanitizer-lld-X86_64 :: dtls_test.c
>>> >> >> lldb-Suite ::
>>> functionalities/register/register_command/TestRegisters.py
>>> >> >> lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py
>>> >> >
>>> >> > It’s hard to diagnose dotest failures without the log.
>>> >> >
>>> >> > (My last reply to this was rejected by the list because I wasn't
>>> subscribed.  Trying again.)
>>> >> >
>>> >> > I have no experience debugging lldb.  Here's the lit output for the
>>> last fail (now at r350377), but let me know if you want something more:
>>> >> >
>>> >> > ```
>>> >> > FAIL: lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py
>>> (59083 of 59736)
>>> >> >  TEST 'lldb-Suite ::
>>> tools/lldb-server/TestGdbRemoteRegisterState.py' FAILED 
>>> >> > lldb version 8.0.0
>>> >> > LLDB library dir: /home/jdenny/ornl/llvm-mono-git-build/bin
>>> >> > LLDB import library dir: /home/jdenny/ornl/llvm-mono-git-build/bin
>>> >> > Libc++ tests will not be run because: Unable to find libc++
>>> installation
>>> >> > Skipping following debug info categories: ['dsym', 'gmodules']
>>> >> >
>>> >> > Session logs for test failures/errors/unexpected successes will go
>>> into directory '/home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces'
>>> >> > Command invoked:
>>> /home/jdenny/ornl/llvm-mono-git/lldb/test/dotest.py -q --arch=x86_64 -s
>>> /home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces --build-dir
>>> /home/jdenny/ornl/llvm-mono-git-build/lldb-test-build.noindex -S nm -u
>>> CXXFLAGS -u CFLAGS --executable
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/lldb --dsymutil
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/dsymutil --filecheck
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/FileCheck -C
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/clang --env
>>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
>>> /home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server
>>> -p TestGdbRemoteRegisterState.py
>>> >> > UNSUPPORTED: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_no_suffix_debugserver
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests)
>>> >> > FAIL: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_no_suffix_llgs
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)
>>> >> > lldb-server exiting...
>>> >> > UNSUPPORTED: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_with_suffix_debugserver
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests)
>>> >> > FAIL: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::

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

[Tom Stellard via lldb-dev]

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

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

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