[lldb-dev] [Bug 35654] LLDB Does not print the correct value for a variable (suspect NRVO alias issue)

2017-12-15 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=35654

lab...@google.com changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |jing...@apple.com

--- Comment #6 from lab...@google.com ---
Thanks for the binaries.

This here seems to be the key (diff of output of llvm-dwarfdump on main.o):
 0x006e: DW_TAG_variable
   DW_AT_location   (0x
- 0x0028 - 0x0041: DW_OP_breg6
RBP-24)
+ 0x0028 - 0x0041: DW_OP_breg6
RBP-24, DW_OP_deref)
   DW_AT_name   ("r")

(the - is your file, the + is the file generated by my clang).

It seems that the xcode clang forgot to add the OP_deref opcode to the location
of the r variable. This means lldb will go looking for in in the wrong place
and display garbage.

Since the behavior is correct on older clangs as well as on current master, I
assume that the Xcode branched clang off of some revision that had this broken.
There isn't much we can do about this from the debugger side, but I'll assign
this to our xcode folks, to see if they can do anything about the compiler
itself.

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

[lldb-dev] [Bug 35671] New: Debugserver does not propagate environment when launching with a pre-loaded inferior

2017-12-15 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=35671

Bug ID: 35671
   Summary: Debugserver does not propagate environment when
launching with a pre-loaded inferior
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org

See test added in . When run against
debugserver, the test fails because the inferior does not find the variable in
its environment.

I tried debugging /usr/bin/env this way, and it printed nothing, so I guess
it's not propagating anything (just like lldb-server wasn't before that patch).

I am not sure how much we care about the launch mode of debugserver, but in any
case, it sounds like a bug. For the time being, I will disable that test on
debugserver, but I'll take a look at how easy will it be to fix it.

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

[lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-15 Thread xgsa via lldb-dev 
Hi, I am working on issue that in C++ program for some complex cases with templates showing dynamic type based on RTTI in lldb doesn't work properly. Consider the following example:enum class TagType : bool {
    Tag1
};

struct I {
    virtual ~I() = default;
};

template 
struct Impl : public I {
    private:
    int v = 123;
};

int main(int argc, const char * argv[]) {
    Impl impl;
    I& i = impl;
    return 0;
}For this example clang generates type name "Impl" in DWARF and "__ZTS4ImplIL7TagType0EE" when mangling symbols (which lldb demangles to Impl<(TagType)0>). Thus when in ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress() lldb tries to resolve the type, it is unable to find it. More cases and the detailed description why lldb fails here can be found in this clang review, which tries to fix this in clang [1]. However, during the discussion around this review [2], it was pointed out that DWARF names are expected to be close to sources, which clang does perfectly, whereas mangling algorithm is strictly defined. Thus matching them on equality could sometimes fail. The suggested idea in [2] was to implement more semantically aware matching. There is enough information in the DWARF to semantically match "Impl<(TagType)0>)" with "Impl", as enum TagType is in the DWARF, and the enumerator Tag1 is present with its value 0. I have some concerns about the performance of such solution, but I'd like to know your opinion about this idea in general. In case it is approved, I'm going to work on implementing it. So what do you think about type names inequality and the suggested solution? [1] - https://reviews.llvm.org/D39622[2] - http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171211/212859.html Thank you,Anton.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-15 Thread xgsa via lldb-dev 
Sorry, I probably shouldn't have used HTML for that message. Converted to plain 
text.

 Original message 
15.12.2017, 18:01, "xgsa" :

Hi,

I am working on issue that in C++ program for some complex cases with templates 
showing dynamic type based on RTTI in lldb doesn't work properly. Consider the 
following example:
enum class TagType : bool
{
Tag1
};

struct I
{
virtual ~I() = default;
};

template 
struct Impl : public I
{
private:
int v = 123;
};

int main(int argc, const char * argv[]) {
Impl impl;
I& i = impl;
return 0;
}

For this example clang generates type name "Impl" in DWARF and 
"__ZTS4ImplIL7TagType0EE" when mangling symbols (which lldb demangles to 
Impl<(TagType)0>). Thus when in 
ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress() lldb tries to resolve 
the type, it is unable to find it. More cases and the detailed description why 
lldb fails here can be found in this clang review, which tries to fix this in 
clang [1].

However, during the discussion around this review [2], it was pointed out that 
DWARF names are expected to be close to sources, which clang does perfectly, 
whereas mangling algorithm is strictly defined. Thus matching them on equality 
could sometimes fail. The suggested idea in [2] was to implement more 
semantically aware matching. There is enough information in the DWARF to 
semantically match "Impl<(TagType)0>)" with "Impl", as enum 
TagType is in the DWARF, and the enumerator Tag1 is present with its value 0. I 
have some concerns about the performance of such solution, but I'd like to know 
your opinion about this idea in general. In case it is approved, I'm going to 
work on implementing it.

So what do you think about type names inequality and the suggested solution?

[1] - https://reviews.llvm.org/D39622
[2] - 
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171211/212859.html

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

Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the release

2017-12-15 Thread Hans Wennborg via lldb-dev 
On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth  wrote:
> FWIW, I don't have really strong objections, but I'm honestly not a fan. The
> reason is mostly that I think it is very late to make the change and likely
> to mean most people are on holiday when the branch occurs. I somewhat
> anticipate significantly more cherrypicks as a consequence. I'd love for
> Apple's releases to by sync'd with the open source ones, but I don't
> understand why one week earlier is so critical. That said, I generally defer
> to those who are working more heavily on the open source releases.

Thanks for your input. I'm not too worried given that the idea is to
start slowly and ramp up testing with RC1 which will happen around the
time it normally would. Let's see how it goes.


> The one thing I have a stronger opinion about is the idea of a "feature
> freeze", stabilization period, or other change. I'm pretty strongly opposed
> to this. One of the things that I most appreciate about the LLVM community
> and process is that the top-of-tree is always open, always active, and
> always kept green.

I agree. Releases should happen on a branch and not obstruct
development on trunk (besides the common courtesy of not landing
majorly disruptive changes righ before the branch as you mentioned
below). I'm not suggesting any changes here.


> On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev
>  wrote:
>>
>> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg  wrote:
>> > Hello everyone,
>> >
>> > It's time to start making plans for the 6.0.0 release.
>> >
>> > Following our regular schedule, the branch would occur about two weeks
>> > into January, on Wednesday 17 January 2018, with the goal of shipping
>> > early March. This is the schedule I would propose.
>> >
>> > However, one large consumer of the branch has asked if we could start
>> > earlier this time, branching on 3 January instead (not moving the ship
>> > date), to get a longer period for stabilization that syncs with their
>> > internal process.
>> >
>> > While I'm hesitant to change the schedule because I think it's
>> > important that it's predictable, there is a benefit of having large
>> > users "in sync" with the upstream release branch, as that means more
>> > people testing the same code.
>> >
>> > I will be out of the office the first weeks of January (and I'm
>> > guessing other members of the community might be too), so while I
>> > could get the branch started on the 3rd, it would be a kind of
>> > "slow-start" of the process, but still allow those who want to start
>> > testing and nominating merges to do so.
>> >
>> > Ultimately, it comes down to what the community prefers. Should we
>> > stick to the regular schedule, or should we do the "slow-start" two
>> > weeks early this time?
>> >
>> > Let me know what you think, especially those of you involved in the
>> > release testing.
>>
>> Since there wasn't really any opposition to the 3 January "slow start"
>> suggestion, let's go with that. I propose the following schedule:
>>
>> 3 January 2018 - Branch point. Those who want can start testing and
>> nominating merges.
>> 17 January 2018 - Release Candidate 1 tag, testing of that starts.
>> 7 February 2018 - Release Candidate 2, things should ideally look
>> pretty good now
>> 21 February 2018 - Final tag. (Typically this slips a bit; just try
>> not to slip into March.)
>>
>> Unless there are any objections, I'll post this on the web page soon.
>>
>> Cheers,
>> Hans
>> ___
>> Openmp-dev mailing list
>> openmp-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the release

2017-12-15 Thread Robinson, Paul via lldb-dev 


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans
> Wennborg via lldb-dev
> Sent: Friday, December 15, 2017 10:07 AM
> To: Chandler Carruth
> Cc: llvm-dev; Release-testers; cfe-dev; openmp-dev (openmp-
> d...@lists.llvm.org); LLDB Dev
> Subject: Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the
> release
> 
> On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth 
> wrote:
> > FWIW, I don't have really strong objections, but I'm honestly not a fan.
> The
> > reason is mostly that I think it is very late to make the change and
> likely
> > to mean most people are on holiday when the branch occurs. I somewhat
> > anticipate significantly more cherrypicks as a consequence. I'd love for
> > Apple's releases to by sync'd with the open source ones, but I don't
> > understand why one week earlier is so critical. That said, I generally
> defer
> > to those who are working more heavily on the open source releases.
> 
> Thanks for your input. I'm not too worried given that the idea is to
> start slowly and ramp up testing with RC1 which will happen around the
> time it normally would. Let's see how it goes.
> 
> 
> > The one thing I have a stronger opinion about is the idea of a "feature
> > freeze", stabilization period, or other change. I'm pretty strongly
> opposed
> > to this. One of the things that I most appreciate about the LLVM
> community
> > and process is that the top-of-tree is always open, always active, and
> > always kept green.
> 
> I agree. Releases should happen on a branch and not obstruct
> development on trunk (besides the common courtesy of not landing
> majorly disruptive changes righ before the branch as you mentioned
> below). I'm not suggesting any changes here.

FTR it's majorly disruptive changes right *after* the branch that
cause the most headaches for cherry-picking fixes.
--paulr

> 
> 
> > On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev
> >  wrote:
> >>
> >> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg 
> wrote:
> >> > Hello everyone,
> >> >
> >> > It's time to start making plans for the 6.0.0 release.
> >> >
> >> > Following our regular schedule, the branch would occur about two
> weeks
> >> > into January, on Wednesday 17 January 2018, with the goal of shipping
> >> > early March. This is the schedule I would propose.
> >> >
> >> > However, one large consumer of the branch has asked if we could start
> >> > earlier this time, branching on 3 January instead (not moving the
> ship
> >> > date), to get a longer period for stabilization that syncs with their
> >> > internal process.
> >> >
> >> > While I'm hesitant to change the schedule because I think it's
> >> > important that it's predictable, there is a benefit of having large
> >> > users "in sync" with the upstream release branch, as that means more
> >> > people testing the same code.
> >> >
> >> > I will be out of the office the first weeks of January (and I'm
> >> > guessing other members of the community might be too), so while I
> >> > could get the branch started on the 3rd, it would be a kind of
> >> > "slow-start" of the process, but still allow those who want to start
> >> > testing and nominating merges to do so.
> >> >
> >> > Ultimately, it comes down to what the community prefers. Should we
> >> > stick to the regular schedule, or should we do the "slow-start" two
> >> > weeks early this time?
> >> >
> >> > Let me know what you think, especially those of you involved in the
> >> > release testing.
> >>
> >> Since there wasn't really any opposition to the 3 January "slow start"
> >> suggestion, let's go with that. I propose the following schedule:
> >>
> >> 3 January 2018 - Branch point. Those who want can start testing and
> >> nominating merges.
> >> 17 January 2018 - Release Candidate 1 tag, testing of that starts.
> >> 7 February 2018 - Release Candidate 2, things should ideally look
> >> pretty good now
> >> 21 February 2018 - Final tag. (Typically this slips a bit; just try
> >> not to slip into March.)
> >>
> >> Unless there are any objections, I'll post this on the web page soon.
> >>
> >> Cheers,
> >> Hans
> >> ___
> >> Openmp-dev mailing list
> >> openmp-...@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-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] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-15 Thread Jim Ingham via lldb-dev 
First off, just a technical point.  lldb doesn't use RTTI to find dynamic 
types, and in fact works for projects like lldb & clang that turn off RTTI.  It 
just uses the fact that the vtable symbol for an object demangles to:

vtable for CLASSNAME

That's not terribly important, but I just wanted to make sure people didn't 
think lldb was doing something fancy with RTTI...  Note, gdb does (or at least 
used to do) dynamic detection the same way.

If the compiler can't be fixed, then it seems like your solution [2] is what 
we'll have to try.

As it works now, we get the CLASSNAME from the vtable symbol and look it up in 
the the list of types.  That is pretty quick because the type names are 
indexed, so we can find it with a quick search in the index.  Changing this 
over to a method where we do some additional string matching rather than just 
using the table's hashing is going to be a fair bit slower because you have to 
run over EVERY type name.  But this might not be that bad.  You would first 
look it up by exact CLASSNAME and only fall back on your fuzzy match if this 
fails, so most dynamic type lookups won't see any slowdown.  And if you know 
the cases where you get into this problem you can probably further restrict 
when you need to do this work so you don't suffer this penalty for every lookup 
where we don't have debug info for the dynamic type.  And you could keep a 
side-table of mangled-name -> DWARF name, and maybe a black-list for unfound 
names, so you only have to do this once.

This estimation is based on the assumption that you can do your work just on 
the type names, without having to get more type information out of the DWARF 
for each candidate match.  A solution that relies on realizing every class in 
lldb so you can get more information out of the type information to help with 
the match will defeat all our attempts at lazy DWARF reading.  This can cause 
quite long delays in big programs.  So I would be much more worried about a 
solution that requires this kind of work.  Again, if you can reject most 
potential candidates by looking at the name, and only have to realize a few 
likely types, the approach might not be that slow.

Jim


> On Dec 15, 2017, at 7:11 AM, xgsa via lldb-dev  
> wrote:
> 
> Sorry, I probably shouldn't have used HTML for that message. Converted to 
> plain text.
> 
>  Original message 
> 15.12.2017, 18:01, "xgsa" :
> 
> Hi,
> 
> I am working on issue that in C++ program for some complex cases with 
> templates showing dynamic type based on RTTI in lldb doesn't work properly. 
> Consider the following example:
> enum class TagType : bool
> {
>Tag1
> };
> 
> struct I
> {
>virtual ~I() = default;
> };
> 
> template 
> struct Impl : public I
> {
> private:
>int v = 123;
> };
> 
> int main(int argc, const char * argv[]) {
>Impl impl;
>I& i = impl;
>return 0;
> }
> 
> For this example clang generates type name "Impl" in DWARF and 
> "__ZTS4ImplIL7TagType0EE" when mangling symbols (which lldb demangles to 
> Impl<(TagType)0>). Thus when in 
> ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress() lldb tries to 
> resolve the type, it is unable to find it. More cases and the detailed 
> description why lldb fails here can be found in this clang review, which 
> tries to fix this in clang [1].
> 
> However, during the discussion around this review [2], it was pointed out 
> that DWARF names are expected to be close to sources, which clang does 
> perfectly, whereas mangling algorithm is strictly defined. Thus matching them 
> on equality could sometimes fail. The suggested idea in [2] was to implement 
> more semantically aware matching. There is enough information in the DWARF to 
> semantically match "Impl<(TagType)0>)" with "Impl", as enum 
> TagType is in the DWARF, and the enumerator Tag1 is present with its value 0. 
> I have some concerns about the performance of such solution, but I'd like to 
> know your opinion about this idea in general. In case it is approved, I'm 
> going to work on implementing it.
> 
> So what do you think about type names inequality and the suggested solution?



> 
> [1] - https://reviews.llvm.org/D39622
> [2] - 
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171211/212859.html
> 
> Thank you,
> Anton.
> ___
> 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