Re: [lldb-dev] [cfe-dev] [Release-testers] [9.0.0 Release] Release Candidate 3 is here
ARM & AArch64 uploaded: 655d6ed6f8038d3203aa446e7dad11f63eeb58625bce6b381e4a5e5cc90e9d4c clang+llvm-9.0.0-rc3-aarch64-linux-gnu.tar.xz ee9a69a75616a2d0fe60b04b78fcfdb04cf1668960d15ba064b7557e2ccf80f9 clang+llvm-9.0.0-rc3-armv7a-linux-gnueabihf.tar.xz No new hiccups. Cheers, Diana On Mon, 2 Sep 2019 at 17:38, Michał Górny via cfe-dev wrote: > > On Sun, 2019-09-01 at 16:21 +0200, Michał Górny via Release-testers > wrote: > > On Fri, 2019-08-30 at 18:38 +0200, Hans Wennborg via Release-testers > > wrote: > > > Hello everyone, > > > > > > 9.0.0-rc3 was tagged today from the release_90 branch at r370450. In > > > the Git monorepo, it's tagged as llvmorg-9.0.0-rc3. > > > > > > Source code and docs are available at > > > https://prereleases.llvm.org/9.0.0/#rc3 > > > > > > Binaries will be added as they become available. > > > > > > There are currently no open release blockers, which means if nothing > > > new comes up, the final release could ship soon and this is what it > > > would look like (except for more release notes, which are still very > > > welcome). > > > > > > > I'm sorry for noticing it this late (I was on vacation) but it seems > > that 9.x has some regression that causes the following tests to hang > > on NetBSD: > > > > LLVM :: ExecutionEngine/MCJIT/eh-lg-pic.ll > > LLVM :: ExecutionEngine/MCJIT/eh.ll > > LLVM :: ExecutionEngine/MCJIT/multi-module-eh-a.ll > > LLVM :: ExecutionEngine/OrcMCJIT/eh-lg-pic.ll > > LLVM :: ExecutionEngine/OrcMCJIT/eh.ll > > LLVM :: ExecutionEngine/OrcMCJIT/multi-module-eh-a.ll > > > > I've been able to pinpoint first bad commit as r364550: > > > > Bitcode: derive all types used from records instead of Values. > > > > However, it seems that trunk works fine. I'm currently searching > > for a possible fix, and I will request backporting once I find it. > > > > I've filed [1] for the backport. However, it seems that we need this > linking for reasons other than listed in the commit message. > > [1] https://bugs.llvm.org/show_bug.cgi?id=43196 > > -- > Best regards, > Michał Górny > > ___ > 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] Breakpoint matching with -n seems to have gotten too generous
Yikes. This is how it is coded currently as we do a search by removing any decl
context and then making sure all resulting strings match by starting with
"A::AMethod", strip off the basename so we get "AMethod", search for all
matches, and then we currently make sure the result contains "A::AMethod".
Since "AA::AMethod" contains it, it matches. This is how it has always been.
What we need to do is to ensure there is a decl context boundary ("::" for C++)
or the start of the string where the match started.
Greg
> On Aug 29, 2019, at 5:33 PM, Jim Ingham via lldb-dev
> wrote:
>
> If I have a program like:
>
> class A {
> public:
> int AMethod() { return 100; }
> };
>
> class AA {
> public:
> int AMethod() { return 200; }
> };
>
> int
> main()
> {
> A myA;
> AA myAA;
> myA.AMethod();
> myAA.AMethod();
> return 0;
> }
>
> Build and run it under lldb, and do:
>
> (lldb) b s -n A::AMethod
> Breakpoint 1: 2 locations.
> (lldb) break list
> Current breakpoints:
> 1: name = 'A::AMethod', locations = 2
> 1.1: where = many_names`A::AMethod() + 8 at many_names.cpp:3:19, address =
> many_names[0x00010f78], unresolved, hit count = 0
> 1.2: where = many_names`AA::AMethod() + 8 at many_names.cpp:8:19, address =
> many_names[0x00010f88], unresolved, hit count = 0
>
> I think that's wrong. The point of the fuzziness in -n is that you can leave
> out containing namespaces, or arguments, and we'll still match what you've
> given us. But IMO that should only expand the search into containing
> contexts. It is surprising to me that if I specify A::AMethod, I also match
> the one in the namespace AA. If you wanted to match .*A::AMethod, you could
> do that with a regular expression. But there's no easy way to not pick up
> extra breakpoints if you happen to have overlaps like this, so it seems like
> expanding -n to strstr type matches seems like a bad idea.
>
> I wondered if other folks thought this was desirable behavior.
>
> 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
[lldb-dev] September LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 5th at 7pm! If you can, help us plan and RSVP here: https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzmbhb/ See everyone there! ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
