Re: [lldb-dev] What are the 'rules' to play nice with lldb-9?

[Adrian Prantl via lldb-dev]

> On Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev 
>  wrote:
> 
> I'm thoroughly confused so I may say incorrect thing. I don't expect any 
> replies to this entire post but bits would be helpful. I'll double check if 
> you need me to be specific since it's likely I remember or ran something 
> wrong. For my language I output llvm-ir directly so I may generate llvm-ir 
> that the llvm api does not and I may create very specific ir if I need to.
> 
> I noticed a number of things. When I declare something with llvm.dbg.declare 
> it doesn't happen where I declare it but at the start of the function? I put 
> my alloca's at the start of the function like llvm recommends so I have 
> invalid pointers and invalid array sizes which causes vscode to crash. Which 
> is fine I'm sure I can write null and say the size is 0 before the first line 
> of the function.

These are really LLVM questions. Basically:

- if you can see the variable with dwarfdump and it doesn't show up in LLDB, 
you should ask on lldb-dev
- if you can't see the variable with dwarfdump, you should ask on llvm-dev

A golden rule of thumb is to look at what clang is doing and copy that.

The location of a dbg.declare is mostly irrelevant, since there can only be one 
dbg.declare per variable and it is valid throughout the entire scope.

> I thought maybe I can use llvm.dbg.addr to work around the problem but I 
> never got it working in the way I hoped (Does it execute at the start of the 
> function? which explains why my unexpected results).

I don't understand the question here. It would be helpful to post a minimal 
example, and look at the output of -print-after-all to see how it is 
transformed by the various passes, so you can ask a more directed question.

> I manage to have some good results with llvm.dbg.value. I noticed if I put a 
> value in a local variable and use `llvm.dbg.value(i64 %abc` there's a high 
> likelihood it will have an incorrect value or will be wrong once I step 
> through more code. However i64 1234 always seem to work.
> 
> How should I tell the debugger about my variables? This page says you are 
> "transitioning away from" llvm.dbg.declare 
> https://llvm.org/docs/SourceLevelDebugging.html I see llvm.dbg.addr says to 
> only use it once and I had some luck with llvm.dbg.value. How do I decide 
> when to use llvm.dbg.value vs llvm.dbg.addr? May I use llvm.dbg.value on a 
> variable that I didn't specific with llvm.dbg.addr? (for example a const 
> value in a variable that has no address)? What about an array passed in from 
> a function? Do I need to store the pointer and or length to a variable to 
> give it an address before the debugger can understand it? 

If your variables "live" on the stack, such as in clang -O0 code, you should 
use one dbg.declare per variable. Otherwise you'll need at least one dbg.value 
per SSA value that carries a variable value.

> 
> Is it possible to say ignore my variable until I hit this specific?
> My language uses constructors so I often have to execute code before pointers 
> become valid.

Yes, dbg.value(undef, ...) followed by another dbg.value will do that 
explicitly.

You can not achieve this with dbg.declare because it is global.

> The language also cleans up so on a return statement as a 'hack' I execute 
> `br false, label %dummy123, label %dummy123, !dbg !123\ndummy123:\n` so the 
> user can see the variables before the cleanup happens/pointers get freed. I 
> mentioned earlier when using vscode having invalid array pointer and invalid 
> size (very large number) made vscode crash. I'm not sure what happened but I 
> had lldb-mi-9 take up many gb (30gb+) in some situations so it may not be a 
> literal crash in the process but locks up and do undesirable behavior
> 
> I don't expect to get all the answers but maybe a piece here and there will 
> help. Should I continue to use llvm.dbg.declare for now with lldb 9? or 
> should I use llvm.dbg.addr and llvm.dbg.value?

Depends on the kind of code you generate.

> Should I always initialize my variables to 0? (so I don't crash vscode when 
> it uses lldb-mi-9) Is there a way I can say ignore this variable until I hit 
> line X where I know the memory will be initialized fully? Do I need to worry 
> about the order I initialize variables or the order I call llvm.dbg.addr? (I 
> remember, call llvm.dbg.addr once per variable)
> 
> Thank you for reading and thank you for any help
> 
> ___
> 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] Is bitcast breaking lldb a bug?

[Adrian Prantl via lldb-dev]

Does this still reproduce with lldb compiled from the current state of the git 
repository (ToT)?

How do you know that it is LLDB loosing the variable and not clang? Does clang 
produce a location for the variable when you look at the dwarfdump output?

-- adrian

> On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev 
>  wrote:
> 
> This feels like a bug to me. Yesterday I was asking what the rules were 
> because it felt like things change and break randomly. Now I have a good 
> example. (link to my email yesterday 
> http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html 
> )
> 
> Take this example source file
> 
> int main() {
> int dummy = 25;
> short wtf[dummy];
> memset(wtf, 0, dummy*sizeof(*wtf));
> return 0;
> }
> 
> Now emit the llvm-ir so we can edit it 
> 
> clang -g test.c -S -emit-llvm
> 
> Before line 21 write this line
> 
> %z8 = bitcast i16* %8 to i16*
> 
> Change the `metadata i16* %8` to `metadata i16* %z8`. Compile it then debug 
> line 4 `clang -g wtf.ll` `lldb-9 ./a.out` `break set -f test.c -l 4` `r` 
> `frame variable`
> 
> You'll see the array doesn't show up. If you change %z8 back to %8 it will 
> reappear. Is this a bug or can I not use bitcast when I'm trying to do things 
> with llvm.dbg.declare/addr/value?
> 
> ___
> 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] LLDB Website is not being updated

[Adrian Prantl via lldb-dev]

Hello Tanya,

I just looked at the LLDB website and it still displays the out-of-date 
"version 8" page. Did you get a chance to investigate this in the mean time?

thanks,
adrian

> On Nov 24, 2019, at 8:30 AM, Tanya Lattner  wrote:
> 
> I’ll have to check the status of moving the scripts over and what is going 
> on. But yes, this is all related to moving to GitHub and modifying scripts 
> that used to be either on a post-commit hook or nightly cron.
> 
> -Tanya
> 
>> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere  wrote:
>> 
>> I see a bunch of eros here:
>> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html
>> 
>> Is this possibly related to the Github/monorepo transition?
>> 
>> -- Jonas
>> 
>> On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev
>>  wrote:
>>> 
>>> Hello Tanya,
>>> 
>>> it looks like the cron job that is supposed to be updating the LLDB website 
>>> isn't running or is otherwise blocked at the moment. You can see on 
>>> https://lldb.llvm.org that it says "Welcome to the LLDB version 8 
>>> documentation!". We also recently removed the "Why a New Debugger?" 
>>> headline and that change isn't showing up either.
>>> 
>>> Would you mind taking a look?
>>> 
>>> thanks for your help,
>>> Adrian
>>> ___
>>> 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] LLDB Website is not being updated

[Jonas Devlieghere via lldb-dev]

Hey Adrian,

The version is hard-coded in lldb/docs/conf.py, we just need to update it
there. As far as I know the website is being updated nightly.

Cheers,
Jonas

On Mon, Mar 2, 2020 at 1:41 PM Adrian Prantl  wrote:

> Hello Tanya,
>
> I just looked at the LLDB website and it still displays the out-of-date
> "version 8" page. Did you get a chance to investigate this in the mean time?
>
> thanks,
> adrian
>
> > On Nov 24, 2019, at 8:30 AM, Tanya Lattner 
> wrote:
> >
> > I’ll have to check the status of moving the scripts over and what is
> going on. But yes, this is all related to moving to GitHub and modifying
> scripts that used to be either on a post-commit hook or nightly cron.
> >
> > -Tanya
> >
> >> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere 
> wrote:
> >>
> >> I see a bunch of eros here:
> >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html
> >>
> >> Is this possibly related to the Github/monorepo transition?
> >>
> >> -- Jonas
> >>
> >> On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev
> >>  wrote:
> >>>
> >>> Hello Tanya,
> >>>
> >>> it looks like the cron job that is supposed to be updating the LLDB
> website isn't running or is otherwise blocked at the moment. You can see on
> https://lldb.llvm.org that it says "Welcome to the LLDB version 8
> documentation!". We also recently removed the "Why a New Debugger?"
> headline and that change isn't showing up either.
> >>>
> >>> Would you mind taking a look?
> >>>
> >>> thanks for your help,
> >>> Adrian
> >>> ___
> >>> 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] LLDB Website is not being updated

[Adrian Prantl via lldb-dev]

Ah, that's great! We should probably just don't print a version on this variant 
and/or add a box like the one at the top of http://llvm.org/docs/ 
.

thanks,
adrian

> On Mar 2, 2020, at 1:43 PM, Jonas Devlieghere  wrote:
> 
> Hey Adrian,
> 
> The version is hard-coded in lldb/docs/conf.py, we just need to update it 
> there. As far as I know the website is being updated nightly.
> 
> Cheers,
> Jonas
> 
> On Mon, Mar 2, 2020 at 1:41 PM Adrian Prantl  > wrote:
> Hello Tanya,
> 
> I just looked at the LLDB website and it still displays the out-of-date 
> "version 8" page. Did you get a chance to investigate this in the mean time?
> 
> thanks,
> adrian
> 
> > On Nov 24, 2019, at 8:30 AM, Tanya Lattner  > > wrote:
> > 
> > I’ll have to check the status of moving the scripts over and what is going 
> > on. But yes, this is all related to moving to GitHub and modifying scripts 
> > that used to be either on a post-commit hook or nightly cron.
> > 
> > -Tanya
> > 
> >> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere  >> > wrote:
> >> 
> >> I see a bunch of eros here:
> >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html 
> >> 
> >> 
> >> Is this possibly related to the Github/monorepo transition?
> >> 
> >> -- Jonas
> >> 
> >> On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev
> >> mailto:lldb-dev@lists.llvm.org>> wrote:
> >>> 
> >>> Hello Tanya,
> >>> 
> >>> it looks like the cron job that is supposed to be updating the LLDB 
> >>> website isn't running or is otherwise blocked at the moment. You can see 
> >>> on https://lldb.llvm.org  that it says "Welcome 
> >>> to the LLDB version 8 documentation!". We also recently removed the "Why 
> >>> a New Debugger?" headline and that change isn't showing up either.
> >>> 
> >>> Would you mind taking a look?
> >>> 
> >>> thanks for your help,
> >>> Adrian
> >>> ___
> >>> 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] LLDB Website is not being updated

[Jonas Devlieghere via lldb-dev]

I removed the version number from the home page.

To github.com:llvm/llvm-project.git
   adc69729ec8..c77fc00eec0  master -> master

I'm not sure we should have the banner because (1) the documentation
doesn't change as much as llvm/clang and (2) we don't archive the old
documentation so there's nothing to link to.

On Mon, Mar 2, 2020 at 1:47 PM Adrian Prantl  wrote:

> Ah, that's great! We should probably just don't print a version on this
> variant and/or add a box like the one at the top of http://llvm.org/docs/.
>
> thanks,
> adrian
>
> On Mar 2, 2020, at 1:43 PM, Jonas Devlieghere 
> wrote:
>
> Hey Adrian,
>
> The version is hard-coded in lldb/docs/conf.py, we just need to update it
> there. As far as I know the website is being updated nightly.
>
> Cheers,
> Jonas
>
> On Mon, Mar 2, 2020 at 1:41 PM Adrian Prantl  wrote:
>
>> Hello Tanya,
>>
>> I just looked at the LLDB website and it still displays the out-of-date
>> "version 8" page. Did you get a chance to investigate this in the mean time?
>>
>> thanks,
>> adrian
>>
>> > On Nov 24, 2019, at 8:30 AM, Tanya Lattner 
>> wrote:
>> >
>> > I’ll have to check the status of moving the scripts over and what is
>> going on. But yes, this is all related to moving to GitHub and modifying
>> scripts that used to be either on a post-commit hook or nightly cron.
>> >
>> > -Tanya
>> >
>> >> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere 
>> wrote:
>> >>
>> >> I see a bunch of eros here:
>> >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html
>> >>
>> >> Is this possibly related to the Github/monorepo transition?
>> >>
>> >> -- Jonas
>> >>
>> >> On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev
>> >>  wrote:
>> >>>
>> >>> Hello Tanya,
>> >>>
>> >>> it looks like the cron job that is supposed to be updating the LLDB
>> website isn't running or is otherwise blocked at the moment. You can see on
>> https://lldb.llvm.org that it says "Welcome to the LLDB version 8
>> documentation!". We also recently removed the "Why a New Debugger?"
>> headline and that change isn't showing up either.
>> >>>
>> >>> Would you mind taking a look?
>> >>>
>> >>> thanks for your help,
>> >>> Adrian
>> >>> ___
>> >>> 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] Is bitcast breaking lldb a bug?

[Levo DeLellis via lldb-dev]

To answer your question, I have no idea. I have limited knowledge of DWARF,
LLDB and LLVM. I haven't tried to compile llvm, lldb or anything (meaning I
only tried in llvm 9 and lldb 9). I been working on my language far to much
to be looking at anything else and this isn't really blocking my progress.


On Mon, Mar 2, 2020 at 4:04 PM Adrian Prantl  wrote:

> Does this still reproduce with lldb compiled from the current state of the
> git repository (ToT)?
>
> How do you know that it is LLDB loosing the variable and not clang? Does
> clang produce a location for the variable when you look at the dwarfdump
> output?
>
> -- adrian
>
> On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> This feels like a bug to me. Yesterday I was asking what the rules were
> because it felt like things change and break randomly. Now I have a good
> example. (link to my email yesterday
> http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html)
>
> Take this example source file
>
> int main() {
> int dummy = 25;
> short wtf[dummy];
> memset(wtf, 0, dummy*sizeof(*wtf));
> return 0;
> }
>
> Now emit the llvm-ir so we can edit it
>
> clang -g test.c -S -emit-llvm
>
> Before line 21 write this line
>
> %z8 = bitcast i16* %8 to i16*
>
> Change the `metadata i16* %8` to `metadata i16* %z8`. Compile it then
> debug line 4 `clang -g wtf.ll` `lldb-9 ./a.out` `break set -f test.c -l 4`
> `r` `frame variable`
>
> You'll see the array doesn't show up. If you change %z8 back to %8 it will
> reappear. Is this a bug or can I not use bitcast when I'm trying to do
> things with llvm.dbg.declare/addr/value?
>
> ___
> 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] Is bitcast breaking lldb a bug?

[Levo DeLellis via lldb-dev]

I took a moment to look at dwarfdump and it seems like it's LLVM that's
causing the problem.

On Mon, Mar 2, 2020 at 4:04 PM Adrian Prantl  wrote:

> Does this still reproduce with lldb compiled from the current state of the
> git repository (ToT)?
>
> How do you know that it is LLDB loosing the variable and not clang? Does
> clang produce a location for the variable when you look at the dwarfdump
> output?
>
> -- adrian
>
> On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> This feels like a bug to me. Yesterday I was asking what the rules were
> because it felt like things change and break randomly. Now I have a good
> example. (link to my email yesterday
> http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html)
>
> Take this example source file
>
> int main() {
> int dummy = 25;
> short wtf[dummy];
> memset(wtf, 0, dummy*sizeof(*wtf));
> return 0;
> }
>
> Now emit the llvm-ir so we can edit it
>
> clang -g test.c -S -emit-llvm
>
> Before line 21 write this line
>
> %z8 = bitcast i16* %8 to i16*
>
> Change the `metadata i16* %8` to `metadata i16* %z8`. Compile it then
> debug line 4 `clang -g wtf.ll` `lldb-9 ./a.out` `break set -f test.c -l 4`
> `r` `frame variable`
>
> You'll see the array doesn't show up. If you change %z8 back to %8 it will
> reappear. Is this a bug or can I not use bitcast when I'm trying to do
> things with llvm.dbg.declare/addr/value?
>
> ___
> 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] What are the 'rules' to play nice with lldb-9?

[Levo DeLellis via lldb-dev]

Thanks this has been very helpful

On Mon, Mar 2, 2020 at 4:02 PM Adrian Prantl  wrote:

>
>
> > On Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I'm thoroughly confused so I may say incorrect thing. I don't expect any
> replies to this entire post but bits would be helpful. I'll double check if
> you need me to be specific since it's likely I remember or ran something
> wrong. For my language I output llvm-ir directly so I may generate llvm-ir
> that the llvm api does not and I may create very specific ir if I need to.
> >
> > I noticed a number of things. When I declare something with
> llvm.dbg.declare it doesn't happen where I declare it but at the start of
> the function? I put my alloca's at the start of the function like llvm
> recommends so I have invalid pointers and invalid array sizes which causes
> vscode to crash. Which is fine I'm sure I can write null and say the size
> is 0 before the first line of the function.
>
> These are really LLVM questions. Basically:
>
> - if you can see the variable with dwarfdump and it doesn't show up in
> LLDB, you should ask on lldb-dev
> - if you can't see the variable with dwarfdump, you should ask on llvm-dev
>
> A golden rule of thumb is to look at what clang is doing and copy that.
>
> The location of a dbg.declare is mostly irrelevant, since there can only
> be one dbg.declare per variable and it is valid throughout the entire scope.
>
> > I thought maybe I can use llvm.dbg.addr to work around the problem but I
> never got it working in the way I hoped (Does it execute at the start of
> the function? which explains why my unexpected results).
>
> I don't understand the question here. It would be helpful to post a
> minimal example, and look at the output of -print-after-all to see how it
> is transformed by the various passes, so you can ask a more directed
> question.
>
> > I manage to have some good results with llvm.dbg.value. I noticed if I
> put a value in a local variable and use `llvm.dbg.value(i64 %abc` there's a
> high likelihood it will have an incorrect value or will be wrong once I
> step through more code. However i64 1234 always seem to work.
> >
> > How should I tell the debugger about my variables? This page says you
> are "transitioning away from" llvm.dbg.declare
> https://llvm.org/docs/SourceLevelDebugging.html I see llvm.dbg.addr says
> to only use it once and I had some luck with llvm.dbg.value. How do I
> decide when to use llvm.dbg.value vs llvm.dbg.addr? May I use
> llvm.dbg.value on a variable that I didn't specific with llvm.dbg.addr?
> (for example a const value in a variable that has no address)? What about
> an array passed in from a function? Do I need to store the pointer and or
> length to a variable to give it an address before the debugger can
> understand it?
>
> If your variables "live" on the stack, such as in clang -O0 code, you
> should use one dbg.declare per variable. Otherwise you'll need at least one
> dbg.value per SSA value that carries a variable value.
>
> >
> > Is it possible to say ignore my variable until I hit this specific?
> > My language uses constructors so I often have to execute code before
> pointers become valid.
>
> Yes, dbg.value(undef, ...) followed by another dbg.value will do that
> explicitly.
>
> You can not achieve this with dbg.declare because it is global.
>
> > The language also cleans up so on a return statement as a 'hack' I
> execute `br false, label %dummy123, label %dummy123, !dbg
> !123\ndummy123:\n` so the user can see the variables before the cleanup
> happens/pointers get freed. I mentioned earlier when using vscode having
> invalid array pointer and invalid size (very large number) made vscode
> crash. I'm not sure what happened but I had lldb-mi-9 take up many gb
> (30gb+) in some situations so it may not be a literal crash in the process
> but locks up and do undesirable behavior
> >
> > I don't expect to get all the answers but maybe a piece here and there
> will help. Should I continue to use llvm.dbg.declare for now with lldb 9?
> or should I use llvm.dbg.addr and llvm.dbg.value?
>
> Depends on the kind of code you generate.
>
> > Should I always initialize my variables to 0? (so I don't crash vscode
> when it uses lldb-mi-9) Is there a way I can say ignore this variable until
> I hit line X where I know the memory will be initialized fully? Do I need
> to worry about the order I initialize variables or the order I call
> llvm.dbg.addr? (I remember, call llvm.dbg.addr once per variable)
> >
> > Thank you for reading and thank you for any help
> >
> > ___
> > 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