Re: [lldb-dev] [Release-testers] 8.0.1-rc4 release has been tagged.

[Tom Stellard via lldb-dev]

On 07/15/2019 05:40 PM, Brian Cain wrote:
> I noticed tests that didn't terminate on ubuntu-14.04 x86_64.  Is PR40761 
> gating this release?
> 

We weren't able to get a fix for that unfortunately.

-Tom
> On Fri, Jul 12, 2019 at 2:21 PM Dimitry Andric via Release-testers 
> mailto:release-test...@lists.llvm.org>> 
> wrote:
> 
> On 11 Jul 2019, at 05:24, Tom Stellard via Release-testers 
> mailto:release-test...@lists.llvm.org>> 
> wrote:
> >
> > I've tagged the 8.0.1-rc4 release, please begin testing.  This will 
> (hopefully)
> > be the last release candidate.  If all goes well, I will tag the final 
> release
> > next Wednesday.
> 
> As with 8.0.1 rc3, I had to disable compiler-rt for this test run, as 
> most of the sanitizers are totally broken. This is tracked in PR40761.
> 
> Main test results on amd64-freebsd11:
> 
> Expected Passes: 53262 (rc3: 53266)
> Passes With Retry  : 1 (rc3: 0)
> Expected Failures  :   213 (rc3:   213)
> Unsupported Tests  :  1718 (rc3:  1718)
> Unresolved Tests   : 8 (rc3: 8)
> Unexpected Passes  : 3 (rc3: 3)
> Unexpected Failures:62 (rc3:59)
> 
> Main test results on i386-freebsd11:
> 
> Expected Passes: 53114 (rc3: 53113)
> Passes With Retry  : 1 (rc3: 0)
> Expected Failures  :   229 (rc3:   229)
> Unsupported Tests  :  1540 (rc3:  1540)
> Unresolved Tests   : 8 (rc3: 7)
> Unexpected Passes  : 5 (rc3: 5)
> Unexpected Failures:   175 (rc3:   178)
> 
> Uploaded:
> 
> SHA256 (clang+llvm-8.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 
> ffd4546aab6d7944b4063a8fd9f4022be8b4904760becc76ee2ea64d3fa50d7e
> SHA256 (clang+llvm-8.0.1-rc4-i386-unknown-freebsd11.tar.xz) = 
> 52ab6fa940a4143c1ac2fc50f2aa0994b92a56fbf7d8b1146b74a7c5de743607
> 
> -Dimitry
> 
> ___
> 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

Re: [lldb-dev] [Release-testers] 8.0.1-rc4 release has been tagged.

[Brian Cain via lldb-dev]

I noticed tests that didn't terminate on ubuntu-14.04 x86_64.  Is PR40761
gating this release?

On Fri, Jul 12, 2019 at 2:21 PM Dimitry Andric via Release-testers <
release-test...@lists.llvm.org> wrote:

> On 11 Jul 2019, at 05:24, Tom Stellard via Release-testers <
> release-test...@lists.llvm.org> wrote:
> >
> > I've tagged the 8.0.1-rc4 release, please begin testing.  This will
> (hopefully)
> > be the last release candidate.  If all goes well, I will tag the final
> release
> > next Wednesday.
>
> As with 8.0.1 rc3, I had to disable compiler-rt for this test run, as most
> of the sanitizers are totally broken. This is tracked in PR40761.
>
> Main test results on amd64-freebsd11:
>
> Expected Passes: 53262 (rc3: 53266)
> Passes With Retry  : 1 (rc3: 0)
> Expected Failures  :   213 (rc3:   213)
> Unsupported Tests  :  1718 (rc3:  1718)
> Unresolved Tests   : 8 (rc3: 8)
> Unexpected Passes  : 3 (rc3: 3)
> Unexpected Failures:62 (rc3:59)
>
> Main test results on i386-freebsd11:
>
> Expected Passes: 53114 (rc3: 53113)
> Passes With Retry  : 1 (rc3: 0)
> Expected Failures  :   229 (rc3:   229)
> Unsupported Tests  :  1540 (rc3:  1540)
> Unresolved Tests   : 8 (rc3: 7)
> Unexpected Passes  : 5 (rc3: 5)
> Unexpected Failures:   175 (rc3:   178)
>
> Uploaded:
>
> SHA256 (clang+llvm-8.0.1-rc4-amd64-unknown-freebsd11.tar.xz) =
> ffd4546aab6d7944b4063a8fd9f4022be8b4904760becc76ee2ea64d3fa50d7e
> SHA256 (clang+llvm-8.0.1-rc4-i386-unknown-freebsd11.tar.xz) =
> 52ab6fa940a4143c1ac2fc50f2aa0994b92a56fbf7d8b1146b74a7c5de743607
>
> -Dimitry
>
> ___
> 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

Re: [lldb-dev] Signal stack unwinding and __kernel_rt_sigreturn

[Jason Molenda via lldb-dev]

> On Jul 12, 2019, at 2:04 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Jun 21, 2019, at 1:24 PM, Joseph Tremoulet via lldb-dev 
>>  wrote:
>> 
> 
>> 2 - When the user handler is invoked, its return address is set to the very 
>> first byte of __kernel_rt_sigreturn, which throws off unwinding because we 
>> assume that frame must really be at a call in the preceding function.  I 
>> asked about this on IRC, where Jan Kratochvil mentioned that the decrement 
>> shouldn't happen for frames with S in the eh_frame's augmentation.  I've 
>> verified that __kernel_rt_sigreturn indeed has the S.  I'm not sure where 
>> I'd find official documentation about that, but the DWARF Standards 
>> Committee's wiki[1] does link to Ian Lance Taylor's blog[2] which says "The 
>> character ‘S’ in the augmentation string means that this CIE represents a 
>> stack frame for the invocation of a signal handler. When unwinding the 
>> stack, signal stack frames are handled slightly differently: the instruction 
>> pointer is assumed to be before the next instruction to execute rather than 
>> after it."  So I'm interested in encoding that knowledge in LLDB, but not 
>> sure architecturally whether it would be more appropriate to dig into the 
>> eh_frame record earlier, or to just have this be a property of symbols 
>> flagged as trap handlers, or something else.
> 
> If we have hints that unwinding should not backup the PC, then this is fine 
> to use. We need the ability to indicate that a lldb_private::StackFrame frame 
> behaves like frame zero even when it is in the middle. I believe the code for 
> sigtramp already does this somehow. I CC'ed Jason Molenda so he can chime in.


Sorry for the delay in replying, yes the discussion over on 
https://reviews.llvm.org/D63667 is also related - we should record the S flag 
in the UnwindPlan but because of the order of operations, always getting the 
eh_frame UnwindPlan to see if this is a signal handler would be expensive (we 
try to delay fetching the eh_frame as much as possible because we pay a 
one-time cost per binary to scan the section).


> 
> 
>> I'd very much appreciate any feedback on this.  I've put up a patch[3] on 
>> Phab with a testcase that demonstrates the issue (on aarch64 linux) and an 
>> implementation of the low-churn "communicate this in the trap handler symbol 
>> list" approach.
>>  
>> Thanks,
>> -Joseph
>>  
>> [1] - http://wiki.dwarfstd.org/index.php?title=Exception_Handling
>> [2] - https://www.airs.com/blog/archives/460
>> [3] - https://reviews.llvm.org/D63667
>>  
>> ___
>> 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] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

[Guilherme Andrade via lldb-dev]

Gábor,
Thanks for pointing this out to me. The AST changes - the resulting log
increases from 7k lines to 11k. I also verified that the fallback branch is
executed. 18k iterations during the first evaluation and 93k afterwards.
However, that only results in a couple extra milliseconds slowness (~ 4
ms), whereas the overall performance hit is in the order of hundreds.

Jim,
Thank you for the explanation. I think I understand the lazy approach for
types realization, but it is still not clear to me how that could cause the
performance to degrade. If we encounter an already realized type, won't
that save us work and make things run faster? Do you know of other points
in the code that could be particularly sensitive to the realized types pool
size (something like the branch Gábor mentioned)?

On Fri, Jul 12, 2019 at 6:08 AM Gábor Márton  wrote:

> Guilherme,
>
> Could you please check if you have any structural differences between the
> ASTs you see when
> 1) you first evaluate your expression at breakpoint A
> 2) you evaluate your expression the second time at breakpoint A ?
> The AST of the expression evaluator's context is dumped once a TagDecl is
> completed, but you need to enable a specific logging: (log enable lldb ast).
>
> I have a theory about the root cause of the slowness you experience, but
> it requires proof from your test scenario.
> There are known problems with the lookup we use in LLDB [1].
> If the lookup mechanism cannot find a symbol then clang::ASTImporter will
> create a new AST node.
> Thus I am expecting a growing AST in your case at 2) with duplicated and
> redundant AST nodes.
> Why would the grown AST results in any slowness?
> Because the lookup we use is in
> `clang::DeclContext::localUncachedLookup()` and it has a fallback branch
> which I assume is executed in your case:
> ```
>   // Slow case: grovel through the declarations in our chain looking for
>   // matches.
>   // FIXME: If we have lazy external declarations, this will not find them!
>   // FIXME: Should we CollectAllContexts and walk them all here?
>   for (Decl *D = FirstDecl; D; D = D->getNextDeclInContext()) {
> if (auto *ND = dyn_cast(D))
>   if (ND->getDeclName() == Name)
> Results.push_back(ND);
>   }
> ```
> This for loop does a linear search on the list of the decls of a decl
> context, which explains the slowing factor as the AST grows.
> I wounder if you could help proving this theorem by first checking if the
> AST grows and if yes then checking if this linear search is executed or not.
>
> [1] If a symbol is in an `extern "C"` block then the existing lookup fails
> to find it. I try to fix it in https://reviews.llvm.org/D61333
>
> Thanks,
> Gabor
>
> On Thu, Jul 11, 2019 at 8:24 PM Jim Ingham via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> lldb realizes types from DWARF lazily.  So for instance, if an expression
>> refers to a pointer to type Foo, we won't necessarily realize the full type
>> of Foo from DWARF to parse that expression.  Then if you write a second
>> expression that accesses a member of an object of type Foo, we will realize
>> the full type for Foo.  Then if you run the first expression again, the
>> pointer to Foo type in the lldb type system will now point to a realized
>> type of Foo.  That should not make any difference, since if we were right
>> the first time that we didn't need to know anything about Foo, it shouldn't
>> matter whether the full type is realized or not.
>>
>> Similarly, the "expression with no side effects" could have also caused
>> lldb to realize any number of other types.  We find names from type
>> information in two ways: looking in the realized types, and looking in the
>> name indexes we read from DWARF or (on systems without accelerator tables)
>> from indexing the DWARF manually.  So the expression with no side effects
>> will change the types in the realized types pool.  That also "should not
>> matter" because if the expression X was looking up by name, the lookup
>> through the name indexes when the type wasn't realized yet should be
>> equivalent to the lookup in the realized types.
>>
>> We really have no choice but to realize types lazily in this way, the
>> debugger would just run way too slowly on big projects if we didn't.  So
>> the fact that one expression can change the state of the type system for a
>> subsequent expression is a fact of life for lldb.  But if the lookup
>> mechanism is working properly, then these changes shouldn't matter.  OTOH
>> shouldn't and don't are not quite the same...
>>
>> Jim
>>
>>
>> > On Jul 11, 2019, at 9:53 AM, Guilherme Andrade 
>> wrote:
>> >
>> > Speaking more generally, can evaluating an expression with no side
>> effects affect the outcome of subsequent evaluations? I.e, is it possible
>> for the expression evaluation X to produce different results in the
>> following scenarios?
>> >
>> > Scenario 1:  > effects>  
>> > Scenario 2:   > evaluation X>
>> >
>> > Thanks!
>> >
>> > On Tue, Jul 

Re: [lldb-dev] Adding a new architecture into LLDB

[Ted Woodward via lldb-dev]

When we added support for Linux running on Hexagon,  we treated it like any 
other Linux. We added the correct register handling, and built it. The issues 
you’re facing we handled in the compiler/rootfs. We built a cross-compiler that 
ran on x86 Linux, targeting Hexagon Linux. We set up a rootfs with all of the 
relevant headers and libraries (MUSL for the C library), told cmake that we 
were targeting Hexagon, and let it fly.

Later on we set up a buildbot that built BusyBox, and had it build our native 
llvm tools as well. We can ssh into a board running Hexagon Linux, and run 
clang/lldb natively. It looks just like x86 Linux.

Ted
From: lldb-dev  On Behalf Of Romaric Jodin via 
lldb-dev
Sent: Monday, July 15, 2019 5:00 AM
To: Greg Clayton 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] Adding a new architecture into LLDB

Indeed, that's exactly what I've done. I've got a "lldb-server-dpu", and the 
only modification I made to have it working as expected is to have a second 
"liblldbHost.a" ("liblldbHostDpu.a"), with a single modification in 
"HostInfoBase::ComputeHostArchitectureSupport" 
(https://github.com/upmem/lldb/commit/d35bbb8376096fd3ab3047b1c5ec507c96731deb#diff-7a05d638d592248e1fbb10192911affbR298)
Seems to work well for the moment.

Romaric

On Fri, Jul 12, 2019 at 11:11 PM Greg Clayton 
mailto:clayb...@gmail.com>> wrote:



On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

Hello everyone,

I am trying to add a new architecture into LLDB.
My architecture is a accelerator with its own ISA for which we have a LLVM 
backend (release 7.1).

I have started by creating a new NativeProcessProtocol for my architecture. So 
I have a lldb-server that run on a x86, but which takes care of process of my 
architecture. I have forced it to use my NativeProcessProtocol.
I have a issue with this method because as the lldb-server is compile to run on 
a x86, some part of the code think that it is managing x86 process.

Maybe I am going in the wrong direction to add such new architecture to LLDB, I 
would be happy to try any other suggestions.

lldb-server is currently meant to build a native debugging GDB server that can 
be used with lldb. If you want to always build a cross build lldb-server for 
your architecture, you will want to add a new tool that gets built in the 
CMakeList.txt in the tools/lldb-server directory. You will need to build it 
into a different binary like "lldb-server-dpu". I am not sure how much trouble 
you will run into doing this though as much of the lldb-server build assumes 
things match the current host.


If you are interested, you can have a look at my branch "dev/rjodin/lldb_dpu" 
in our forked repo of LLDB "https://github.com/upmem/lldb;. The branch is not 
clean, but it can help you understand what I did.

Thanks,
--
Romaric JODIN
UPMEM
Software Engineer


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



--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D53B0A.FB29CCB0]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Type Validation and Dexter

[Tom Weaver via lldb-dev]

Dear LLDB dev community

I'm currently working on an open source project called DExTer. DExTer is
used to help validate and check the debugging experience a user might have
when debugging a program. The LLVM community is interested in using DExTer
as a means to run DebugInfo-Integration tests. A needed feature of DExTer
is to be able to validate arbitrary type information during program
execution.

We're currently trying to implement support for correct type testing in
DExTer. We'd like test writers to be able to validate arbitrary types
exists at some point during program execution. We'd like to be able to
validate the types of PODs, class types, template types amongst others.

Dexter supports multiple debuggers, of which LLDB is one and as we're
pushing for use with LLVM DebugInfo-Integration tests, I've been working on
implementing this functionality with LLDB first.

However, I can't find a way to validate the type of a template parameter.
According to the "GDB to LLDB command map" article :

  https://lldb.llvm.org/use/map.html

LLDB's equivalent to GDB's "ptype" feature is "image lookup --type ".
When using GDB's ptype command it's possible to query the type of a
template parameter, see example below:

1 template
2 T foo(const T & bar) {
3   return bar + bar;
4 }
5
6 int main() {
7   return foo(5);
8 }

I'd like to be able to break on line 3 in the above example and find out
what the type of "T" is in the instantiated template function foo.

With GDB's ptype function, I'm able to type "ptype T" and get back the type
name "int". This doesn't seem to be possible with LLDBs "image lookup
--type" command.

With LLDB, breaking on line 3 and executing the following command "image
lookup --type T" I get back an empty string. I can however, lookup the type
"int" and get back a result.

Similarly, when using the LLDB python API, I can't call
"lldb.SBTarget.FindFirstType('T')" and get back anything other than an
empty SBType object. Again, I can look up the type "int".

So, I'd like to ask, is LLDB capable of validating template parameter
types?

If there isn't support for arbitrary type validating of template parameters
in LLDB, then are there plans for future work to support it? We'd really
like to have this functionality for our DebugInfo-Integration test suite.

Kindest regards,
Tom Weaver.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] 8.0.1-rc4 release has been tagged.

[Diana Picus via lldb-dev]

Hi,

ARM & AArch64 seem fine:
ef4f41dc77483754efee9a6e158f28725f22b29f7e4483a1ab1442b4b75dc7cd
clang+llvm-8.0.1-rc4-aarch64-linux-gnu.tar.xz
39a47e3d1ecedad627153d618afb3d15675a498c67f2691c93382679e3788911
clang+llvm-8.0.1-rc4-armv7a-linux-gnueabihf.tar.xz

Cheers,
Diana

On Thu, 11 Jul 2019 at 05:25, Tom Stellard via cfe-dev
 wrote:
>
> Hi,
>
> I've tagged the 8.0.1-rc4 release, please begin testing.  This will 
> (hopefully)
> be the last release candidate.  If all goes well, I will tag the final release
> next Wednesday.
>
> -Tom
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Adding a new architecture into LLDB

[Romaric Jodin via lldb-dev]

Indeed, that's exactly what I've done. I've got a "lldb-server-dpu", and
the only modification I made to have it working as expected is to have a
second "liblldbHost.a" ("liblldbHostDpu.a"), with a single modification in
"HostInfoBase::ComputeHostArchitectureSupport" (
https://github.com/upmem/lldb/commit/d35bbb8376096fd3ab3047b1c5ec507c96731deb#diff-7a05d638d592248e1fbb10192911affbR298
)
Seems to work well for the moment.

Romaric

On Fri, Jul 12, 2019 at 11:11 PM Greg Clayton  wrote:

>
>
> On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello everyone,
>
> I am trying to add a new architecture into LLDB.
> My architecture is a accelerator with its own ISA for which we have a LLVM
> backend (release 7.1).
>
> I have started by creating a new NativeProcessProtocol for my
> architecture. So I have a lldb-server that run on a x86, but which takes
> care of process of my architecture. I have forced it to use my
> NativeProcessProtocol.
> I have a issue with this method because as the lldb-server is compile to
> run on a x86, some part of the code think that it is managing x86 process.
>
>
> Maybe I am going in the wrong direction to add such new architecture to
> LLDB, I would be happy to try any other suggestions.
>
>
> lldb-server is currently meant to build a native debugging GDB server that
> can be used with lldb. If you want to always build a cross build
> lldb-server for your architecture, you will want to add a new tool that
> gets built in the CMakeList.txt in the tools/lldb-server directory. You
> will need to build it into a different binary like "lldb-server-dpu". I am
> not sure how much trouble you will run into doing this though as much of
> the lldb-server build assumes things match the current host.
>
>
> If you are interested, you can have a look at my branch
> "dev/rjodin/lldb_dpu" in our forked repo of LLDB "
> https://github.com/upmem/lldb;. The branch is not clean, but it can help
> you understand what I did.
>
> Thanks,
> --
> *Romaric JODIN*
> UPMEM
> *Software Engineer*
>
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>

-- 
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev