Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

[Pavel Labath via lldb-dev]

On 20/07/2020 23:25, Jim Ingham wrote:
> It seems like you are having to work hard in the ValueObject system because 
> you don’t want to use single AST Type for the ValueObject’s type.  Seems like 
> it be much simpler if you could cons up a complete type in the 
> ScratchASTContext, and then use the underlying TypeSystem to do the layout 
> computation.
> 
> Preserving the full type in the scratch context also avoids other problems.  
> For instance, suppose module A has a class that has an opaque reference to a 
> type B.  There is a full definition of B in modules B and C.  If you make up 
> a ValueObject for an object of type A resolving the full type to the one in 
> Module B you can get into trouble.  Suppose the next user step is over the 
> dlclose of module B.  When the local variable goes to see if it has changed, 
> it will stumble across a type reference to a module that’s no longer present 
> in the program.  And if somebody calls RemoveOrphanedModules it won’t even be 
> in the shared module cache.
> 
> You can try to finesse this by saying you can choose the type from the 
> defining module so it can’t go away.  But a) I don’t think you can know that 
> for non-virtual classes in C++ and I don’t think you guarantee you can know 
> how to do that for any given language.
> 
> I wonder if it wouldn’t be a better approach to build up a full compiler-type 
> by importing the types you find into the scratch AST context.  That way you 
> know they can’t go away.   And since you still have a full CompilerType for 
> the variable, you can let the languages tell you where to find children based 
> on their knowledge of the types.
> 

I do see the attractiveness of constructing of a full compiler type. The
reason I am hesitant to go that way, because it seems to me that this
would negate the two main benefits of the frame variable command over
the expression evaluator: a) it's fast; b) it's less likely to crash.

And while I don't think it will be as slow or as crashy as the
expression evaluator, the usage of the ast importer will force a lot
more types to be parsed than are strictly needed for this functionality.
And the insertion of all potentially conflicting types from different
modules into a single ast context is also somewhat worrying.

The dlclose issue is an interesting one. Presumably, we could ensure
that the module does not go away by storing a module shared (or weak?)
pointer somewhere inside the value object. BTW, how does this work with
ValueObject casts right now? If I cast a ValueObject to a CompilerType
belonging to a different module, does anything ensure this module does
not go away? Or when dereferencing a pointer to an type which is not
complete in the current module?

I'm hoping that this stuff won't be "hard work". I haven't prototyped
the code yet, but I am hoping to keep this lookup code in under 200 LOC.
And as Greg points out, there are ways to put this stuff into the type
system -- I'm just not sure whether that is needed given that the
ValueObject class is the only user of the GetIndexOfChildMemberWithName
interface. The whole function is pretty clearly designed with
ValueObject::GetChildMemberWithName in mind.

Another thing I like about this approach is that it will mostly use the
same code path for the limit and no-limit debug info scenarios. OTOH,
I'm pretty sure we would want to use the scratch context thingy only for
types that are really not complete in their own modules, which would
leave the scratch context method as a fairly complex, but rarely
exercised path.

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

[lldb-dev] Break setting aliases...

[Jim Ingham via lldb-dev]

When we were first devising commands for lldb, we tried to be really 
parsimonious with the one & two letter unique command strings that lldb ships 
with by default.  I was trying to leave us as much flexibility as possible as 
we evolved, and I also wanted to make sure we weren’t taking up all the 
convenient short commands, leaving a cramped space for user aliases.

The _regex_break command was added (and aliased by default to ‘b’) as a way to 
allow quick access for various common breakpoint setting options.  However it 
suffers from the problem that you can only provide the options that are 
recognized by the _regexp_break command aliases.  For instance, you can’t add 
the -h option to make a hardware breakpoint.  Because the “_regex_break command 
works by passing the command through a series of regex’s stopping at the first 
match, trying to extend the regular expressions to also include “anything else” 
while not causing one regex to claim a command that was really meant for a 
regex further on in the series is really tricky.

That makes it kind of a wall for people.  As soon as you need to do anything it 
doesn’t support you have to go to a command that is not known to you (since “b” 
isn’t related to “break set” in any way that a normal user can actually see.)

However, lldb has been around for a while and we only have two unique commands 
of the form “b[A-Za-z]” in the current lldb command set (br and bt).  So I 
think it would be okay for us to take up a few more second letter commands to 
make setting breakpoints more convenient.  I think adding:

bs (break source) -> break set -y
ba (break address) -> break set -a
bn (break name) -> break set -n

would provide a convenient way to set the most common classes of breakpoints 
while not precluding access to all the other options available to “break set”.  
We could still leave “b” by itself for the _regex_break command - people who’ve 
figured out it’s intricacies shouldn’t lose their investment.  This would be 
purely additive.

What do people think?

Jim

 

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

Re: [lldb-dev] Break setting aliases...

[Jonas Devlieghere via lldb-dev]

I don't mind adding the two-letter commands, but I also don't really see
the value in being able to say `bs` instead of `b s -y`. Until either
becomes muscle memory, both require a little cognitive overhead of thinking
"breakpoint set -y" or "breakpoint source". As a user there would be more
value in knowing that the latter is really `breakpoint set -y` which then
allows you to query the help.

If I understand correctly the problem with `b` is that the regex can't
distinguish easily between what it should parse and what it should forward
to `breakpoint set`. Additionally, because it's essentially a
mini-language, you can't be sure if something with a colon is a symbol or
file separated by a line/column number.

I think we should be able to solve the first issue by making `b` a proper
first-class command instead of a regex alias, taking the exact same options
as `breakpoint set`. I think our existing command object argument parser
should be able to parse this and return the remaining "free form" argument,
which we can then parse as a mini-language like we do today. Of course this
would remain suboptimal, but would be strictly better than what we have
today and address the original problem you're trying to solve. Furthermore,
with a first-class command we can do a better job on the help front which
is really underwhelming for _regexp_break command aliases.

That leaves the second problem, which would be solved by the new two-letter
commands but not by changing `b`. From a purity perspective I'd lean
towards the new commands, but as a user I doubt I would use them. I set
almost all my breakpoints with `b` and I don't see a compelling reason to
change to `bs`. So that leaves me with using `b` most of the time, until I
do need to pass some extra option at which point I'll probably just use
`breakpoint set` directly.

TL;DR: Given how widely used `b` is I'd rather improve that and turn it
from a 98% solution into a 99% solution instead of adding new commands.


On Tue, Jul 21, 2020 at 10:22 AM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> When we were first devising commands for lldb, we tried to be really
> parsimonious with the one & two letter unique command strings that lldb
> ships with by default.  I was trying to leave us as much flexibility as
> possible as we evolved, and I also wanted to make sure we weren’t taking up
> all the convenient short commands, leaving a cramped space for user aliases.
>
> The _regex_break command was added (and aliased by default to ‘b’) as a
> way to allow quick access for various common breakpoint setting options.
> However it suffers from the problem that you can only provide the options
> that are recognized by the _regexp_break command aliases.  For instance,
> you can’t add the -h option to make a hardware breakpoint.  Because the
> “_regex_break command works by passing the command through a series of
> regex’s stopping at the first match, trying to extend the regular
> expressions to also include “anything else” while not causing one regex to
> claim a command that was really meant for a regex further on in the series
> is really tricky.
>
> That makes it kind of a wall for people.  As soon as you need to do
> anything it doesn’t support you have to go to a command that is not known
> to you (since “b” isn’t related to “break set” in any way that a normal
> user can actually see.)
>
> However, lldb has been around for a while and we only have two unique
> commands of the form “b[A-Za-z]” in the current lldb command set (br and
> bt).  So I think it would be okay for us to take up a few more second
> letter commands to make setting breakpoints more convenient.  I think
> adding:
>
> bs (break source) -> break set -y
> ba (break address) -> break set -a
> bn (break name) -> break set -n
>
> would provide a convenient way to set the most common classes of
> breakpoints while not precluding access to all the other options available
> to “break set”.  We could still leave “b” by itself for the _regex_break
> command - people who’ve figured out it’s intricacies shouldn’t lose their
> investment.  This would be purely additive.
>
> What do people think?
>
> Jim
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Break setting aliases...

[Jim Ingham via lldb-dev]

> On Jul 21, 2020, at 11:13 AM, Jonas Devlieghere  wrote:
> 
> I don't mind adding the two-letter commands, but I also don't really see the 
> value in being able to say `bs` instead of `b s -y`. Until either becomes 
> muscle memory, both require a little cognitive overhead of thinking 
> "breakpoint set -y" or "breakpoint source". As a user there would be more 
> value in knowing that the latter is really `breakpoint set -y` which then 
> allows you to query the help.

Yes, I don’t really understand people’s objection to “br s -y” or whatever, and 
peering over people’s shoulders indicates it is not universal.  But there are a 
significant number of folks who are happier with a single command to type and 
“b s -y” seems to be a hinderance.  I was trying to help in this case, not 
trying to understand...

> 
> If I understand correctly the problem with `b` is that the regex can't 
> distinguish easily between what it should parse and what it should forward to 
> `breakpoint set`. Additionally, because it's essentially a mini-language, you 
> can't be sure if something with a colon is a symbol or file separated by a 
> line/column number. 

More that that.  If you type:

(lldb) b f

then we have to complete f in all the collections “b” might access, symbol 
names and file names in this case.  In a substantial project that’s a lot of 
symbols if I meant a file name and vice versa.  And the more we glom into the 
break-specification mini language, the harder this will be.

> 
> I think we should be able to solve the first issue by making `b` a proper 
> first-class command instead of a regex alias, taking the exact same options 
> as `breakpoint set`. I think our existing command object argument parser 
> should be able to parse this and return the remaining "free form" argument, 
> which we can then parse as a mini-language like we do today. Of course this 
> would remain suboptimal, but would be strictly better than what we have today 
> and address the original problem you're trying to solve. Furthermore, with a 
> first-class command we can do a better job on the help front which is really 
> underwhelming for _regexp_break command aliases.
> 
> That leaves the second problem, which would be solved by the new two-letter 
> commands but not by changing `b`. From a purity perspective I'd lean towards 
> the new commands, but as a user I doubt I would use them. I set almost all my 
> breakpoints with `b` and I don't see a compelling reason to change to `bs`. 
> So that leaves me with using `b` most of the time, until I do need to pass 
> some extra option at which point I'll probably just use `breakpoint set` 
> directly. 
> 
> TL;DR: Given how widely used `b` is I'd rather improve that and turn it from 
> a 98% solution into a 99% solution instead of adding new commands.

I was hoping that since “bs”, “ba”, and “bn” are easy to type and would show up 
in a top-level “help” new folks would shift to using those, and maybe extant 
users of “b” would too.  Then we could slide past having the 
“break-specification mini-language” over time.

I was also trying to make things a little better w/o signing up for making 
“_regex_break” work better which I don’t have any intention of doing 
personally...

Jim


> 
> 
> On Tue, Jul 21, 2020 at 10:22 AM Jim Ingham via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> When we were first devising commands for lldb, we tried to be really 
> parsimonious with the one & two letter unique command strings that lldb ships 
> with by default.  I was trying to leave us as much flexibility as possible as 
> we evolved, and I also wanted to make sure we weren’t taking up all the 
> convenient short commands, leaving a cramped space for user aliases.
> 
> The _regex_break command was added (and aliased by default to ‘b’) as a way 
> to allow quick access for various common breakpoint setting options.  However 
> it suffers from the problem that you can only provide the options that are 
> recognized by the _regexp_break command aliases.  For instance, you can’t add 
> the -h option to make a hardware breakpoint.  Because the “_regex_break 
> command works by passing the command through a series of regex’s stopping at 
> the first match, trying to extend the regular expressions to also include 
> “anything else” while not causing one regex to claim a command that was 
> really meant for a regex further on in the series is really tricky.
> 
> That makes it kind of a wall for people.  As soon as you need to do anything 
> it doesn’t support you have to go to a command that is not known to you 
> (since “b” isn’t related to “break set” in any way that a normal user can 
> actually see.)
> 
> However, lldb has been around for a while and we only have two unique 
> commands of the form “b[A-Za-z]” in the current lldb command set (br and bt). 
>  So I think it would be okay for us to take up a few more second letter 
> commands to make setting breakpoints more convenient.  I think ad

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

[Greg Clayton via lldb-dev]

> On Jul 21, 2020, at 9:27 AM, Pavel Labath  wrote:
> 
> On 20/07/2020 23:25, Jim Ingham wrote:
>> It seems like you are having to work hard in the ValueObject system because 
>> you don’t want to use single AST Type for the ValueObject’s type.  Seems 
>> like it be much simpler if you could cons up a complete type in the 
>> ScratchASTContext, and then use the underlying TypeSystem to do the layout 
>> computation.
>> 
>> Preserving the full type in the scratch context also avoids other problems.  
>> For instance, suppose module A has a class that has an opaque reference to a 
>> type B.  There is a full definition of B in modules B and C.  If you make up 
>> a ValueObject for an object of type A resolving the full type to the one in 
>> Module B you can get into trouble.  Suppose the next user step is over the 
>> dlclose of module B.  When the local variable goes to see if it has changed, 
>> it will stumble across a type reference to a module that’s no longer present 
>> in the program.  And if somebody calls RemoveOrphanedModules it won’t even 
>> be in the shared module cache.
>> 
>> You can try to finesse this by saying you can choose the type from the 
>> defining module so it can’t go away.  But a) I don’t think you can know that 
>> for non-virtual classes in C++ and I don’t think you guarantee you can know 
>> how to do that for any given language.
>> 
>> I wonder if it wouldn’t be a better approach to build up a full 
>> compiler-type by importing the types you find into the scratch AST context.  
>> That way you know they can’t go away.   And since you still have a full 
>> CompilerType for the variable, you can let the languages tell you where to 
>> find children based on their knowledge of the types.
>> 
> 
> I do see the attractiveness of constructing of a full compiler type. The
> reason I am hesitant to go that way, because it seems to me that this
> would negate the two main benefits of the frame variable command over
> the expression evaluator: a) it's fast; b) it's less likely to crash.
> 
> And while I don't think it will be as slow or as crashy as the
> expression evaluator, the usage of the ast importer will force a lot
> more types to be parsed than are strictly needed for this functionality.
> And the insertion of all potentially conflicting types from different
> modules into a single ast context is also somewhat worrying.

I agree here. Frame variable should do as little as possible when dealing with 
a ValueObject and its type, so only completing the parts of the type we know 
are transparent it a good approach.
> 
> The dlclose issue is an interesting one. Presumably, we could ensure
> that the module does not go away by storing a module shared (or weak?)
> pointer somewhere inside the value object. BTW, how does this work with
> ValueObject casts right now? If I cast a ValueObject to a CompilerType
> belonging to a different module, does anything ensure this module does
> not go away? Or when dereferencing a pointer to an type which is not
> complete in the current module?

I am not sure dlclose is a problem, the module won't usually be cleaned up. And 
that shared library shouldn't have the definition we need and be able to be 
unloaded IIUC how the -flimit-debug-info stuff works.

> 
> I'm hoping that this stuff won't be "hard work". I haven't prototyped
> the code yet, but I am hoping to keep this lookup code in under 200 LOC.
> And as Greg points out, there are ways to put this stuff into the type
> system -- I'm just not sure whether that is needed given that the
> ValueObject class is the only user of the GetIndexOfChildMemberWithName
> interface. The whole function is pretty clearly designed with
> ValueObject::GetChildMemberWithName in mind.

We should be able to code it into ValueObject, or maybe just into TypeSystem 
base class?
> 
> Another thing I like about this approach is that it will mostly use the
> same code path for the limit and no-limit debug info scenarios. OTOH,
> I'm pretty sure we would want to use the scratch context thingy only for
> types that are really not complete in their own modules, which would
> leave the scratch context method as a fairly complex, but rarely
> exercised path.
> 
> pl

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

Re: [lldb-dev] Break setting aliases...

[Greg Clayton via lldb-dev]

> On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev 
>  wrote:
> 
> When we were first devising commands for lldb, we tried to be really 
> parsimonious with the one & two letter unique command strings that lldb ships 
> with by default.  I was trying to leave us as much flexibility as possible as 
> we evolved, and I also wanted to make sure we weren’t taking up all the 
> convenient short commands, leaving a cramped space for user aliases.
> 
> The _regex_break command was added (and aliased by default to ‘b’) as a way 
> to allow quick access for various common breakpoint setting options.  However 
> it suffers from the problem that you can only provide the options that are 
> recognized by the _regexp_break command aliases.  For instance, you can’t add 
> the -h option to make a hardware breakpoint.  Because the “_regex_break 
> command works by passing the command through a series of regex’s stopping at 
> the first match, trying to extend the regular expressions to also include 
> “anything else” while not causing one regex to claim a command that was 
> really meant for a regex further on in the series is really tricky.
> 
> That makes it kind of a wall for people.  As soon as you need to do anything 
> it doesn’t support you have to go to a command that is not known to you 
> (since “b” isn’t related to “break set” in any way that a normal user can 
> actually see.)
> 
> However, lldb has been around for a while and we only have two unique 
> commands of the form “b[A-Za-z]” in the current lldb command set (br and bt). 
>  So I think it would be okay for us to take up a few more second letter 
> commands to make setting breakpoints more convenient.  I think adding:
> 
> bs (break source) -> break set -y

Is -y a new option you would add? I don't see it. We have --file and --line

> ba (break address) -> break set -a
> bn (break name) -> break set -n
> 
> would provide a convenient way to set the most common classes of breakpoints 
> while not precluding access to all the other options available to “break 
> set”.  We could still leave “b” by itself for the _regex_break command - 
> people who’ve figured out it’s intricacies shouldn’t lose their investment.  
> This would be purely additive.
> 
> What do people think?

Can we modify the _regex_break to accept options at the start or end of the 
command somehow? 



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

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

Re: [lldb-dev] Break setting aliases...

[Jim Ingham via lldb-dev]

> On Jul 21, 2020, at 2:54 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev 
>>  wrote:
>> 
>> When we were first devising commands for lldb, we tried to be really 
>> parsimonious with the one & two letter unique command strings that lldb 
>> ships with by default.  I was trying to leave us as much flexibility as 
>> possible as we evolved, and I also wanted to make sure we weren’t taking up 
>> all the convenient short commands, leaving a cramped space for user aliases.
>> 
>> The _regex_break command was added (and aliased by default to ‘b’) as a way 
>> to allow quick access for various common breakpoint setting options.  
>> However it suffers from the problem that you can only provide the options 
>> that are recognized by the _regexp_break command aliases.  For instance, you 
>> can’t add the -h option to make a hardware breakpoint.  Because the 
>> “_regex_break command works by passing the command through a series of 
>> regex’s stopping at the first match, trying to extend the regular 
>> expressions to also include “anything else” while not causing one regex to 
>> claim a command that was really meant for a regex further on in the series 
>> is really tricky.
>> 
>> That makes it kind of a wall for people.  As soon as you need to do anything 
>> it doesn’t support you have to go to a command that is not known to you 
>> (since “b” isn’t related to “break set” in any way that a normal user can 
>> actually see.)
>> 
>> However, lldb has been around for a while and we only have two unique 
>> commands of the form “b[A-Za-z]” in the current lldb command set (br and 
>> bt).  So I think it would be okay for us to take up a few more second letter 
>> commands to make setting breakpoints more convenient.  I think adding:
>> 
>> bs (break source) -> break set -y
> 
> Is -y a new option you would add? I don't see it. We have --file and --line

Added it yesterday.

> 
>> ba (break address) -> break set -a
>> bn (break name) -> break set -n
>> 
>> would provide a convenient way to set the most common classes of breakpoints 
>> while not precluding access to all the other options available to “break 
>> set”.  We could still leave “b” by itself for the _regex_break command - 
>> people who’ve figured out it’s intricacies shouldn’t lose their investment.  
>> This would be purely additive.
>> 
>> What do people think?
> 
> Can we modify the _regex_break to accept options at the start or end of the 
> command somehow? 
> 

When the principle of so much of the rest of the lldb command line is that this 
sort of positional ordering is NOT necessary, doing this would be a shame.  At 
that point, I think Jonas suggestion of having a command  “break 
break-spec-set” or whatever, that took the breakpoint modify option group and 
then a specifier as an argument(s) which get parsed in the same way that 
“_regexp_break” does would be a better long-term supportable option.

Jim


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

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

[Jim Ingham via lldb-dev]

> On Jul 21, 2020, at 9:27 AM, Pavel Labath  wrote:
> 
> On 20/07/2020 23:25, Jim Ingham wrote:
>> It seems like you are having to work hard in the ValueObject system because 
>> you don’t want to use single AST Type for the ValueObject’s type.  Seems 
>> like it be much simpler if you could cons up a complete type in the 
>> ScratchASTContext, and then use the underlying TypeSystem to do the layout 
>> computation.
>> 
>> Preserving the full type in the scratch context also avoids other problems.  
>> For instance, suppose module A has a class that has an opaque reference to a 
>> type B.  There is a full definition of B in modules B and C.  If you make up 
>> a ValueObject for an object of type A resolving the full type to the one in 
>> Module B you can get into trouble.  Suppose the next user step is over the 
>> dlclose of module B.  When the local variable goes to see if it has changed, 
>> it will stumble across a type reference to a module that’s no longer present 
>> in the program.  And if somebody calls RemoveOrphanedModules it won’t even 
>> be in the shared module cache.
>> 
>> You can try to finesse this by saying you can choose the type from the 
>> defining module so it can’t go away.  But a) I don’t think you can know that 
>> for non-virtual classes in C++ and I don’t think you guarantee you can know 
>> how to do that for any given language.
>> 
>> I wonder if it wouldn’t be a better approach to build up a full 
>> compiler-type by importing the types you find into the scratch AST context.  
>> That way you know they can’t go away.   And since you still have a full 
>> CompilerType for the variable, you can let the languages tell you where to 
>> find children based on their knowledge of the types.
>> 
> 
> I do see the attractiveness of constructing of a full compiler type. The
> reason I am hesitant to go that way, because it seems to me that this
> would negate the two main benefits of the frame variable command over
> the expression evaluator: a) it's fast; b) it's less likely to crash.
> 
> And while I don't think it will be as slow or as crashy as the
> expression evaluator, the usage of the ast importer will force a lot
> more types to be parsed than are strictly needed for this functionality.
> And the insertion of all potentially conflicting types from different
> modules into a single ast context is also somewhat worrying.

Importation should be incremental as well, so this shouldn’t make things that 
much slower.  And you shouldn’t ever be looking things up by name in this AST 
so you wouldn’t be led astray that way.  You also are going to have to do 
pretty much the same job for “expr”, right?  So you wouldn’t be opening new 
dangerous pathways.

OTOH, the AST’s are complex beasts, so I am not unmoved by your worries...

> 
> The dlclose issue is an interesting one. Presumably, we could ensure
> that the module does not go away by storing a module shared (or weak?)
> pointer somewhere inside the value object. BTW, how does this work with
> ValueObject casts right now? If I cast a ValueObject to a CompilerType
> belonging to a different module, does anything ensure this module does
> not go away? Or when dereferencing a pointer to an type which is not
> complete in the current module?

I don’t think at present we do anything smart about this.  It’s just always 
bugged me at the back of my brain that we could get into trouble with this, and 
so I don’t want to do something that would make it worse, especially in a 
systemic way.

> 
> I'm hoping that this stuff won't be "hard work". I haven't prototyped
> the code yet, but I am hoping to keep this lookup code in under 200 LOC.
> And as Greg points out, there are ways to put this stuff into the type
> system -- I'm just not sure whether that is needed given that the
> ValueObject class is the only user of the GetIndexOfChildMemberWithName
> interface. The whole function is pretty clearly designed with
> ValueObject::GetChildMemberWithName in mind.

It seems fine to me to proceed along the lines you propose.  If it ends up 
being smooth sailing, I can’t see any reason not to do it this way.  When/If 
you end up having lots of corner cases to manage, would be the time to consider 
cutting back to using the real type system to back these computations.

> 
> Another thing I like about this approach is that it will mostly use the
> same code path for the limit and no-limit debug info scenarios. OTOH,
> I'm pretty sure we would want to use the scratch context thingy only for
> types that are really not complete in their own modules, which would
> leave the scratch context method as a fairly complex, but rarely
> exercised path.

This is a legit concern, offset a bit by the fact that this is an area where it 
would be fairly easy to construct relevant test scenarios for corner cases. 

Jim

> 
> pl

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

Re: [lldb-dev] [Release-testers] LLVM 10.0.1-final has been tagged

[Brian Cain via lldb-dev]

Uploaded sles12, ubuntu16:

 $ cat clang+llvm-10.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sha256
48b83ef827ac2c213d5b64f5ad7ed082c8bcb712b46644e0dc5045c6f462c231
 clang+llvm-10.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz

$ cat clang+llvm-10.0.1-x86_64-linux-sles12.4.tar.xz.sha256
59f35fc7967b740315edf31a54b228ae5da8a54f499e37d424d67b7107217ae4
 clang+llvm-10.0.1-x86_64-linux-sles12.4.tar.xz

On Tue, Jul 21, 2020 at 12:25 AM Tom Stellard via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hi,
>
> I've tagged 10.0.1-final.  Testers, please begin uploading your binaries.
>
> Thanks,
> Tom
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


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