[lldb-dev] Welcome Alexander!

[Adrian Prantl via lldb-dev]

Please join me in welcoming Alexander Polyakov, who will be working on cleaning 
up and completing LLDB's lldb-mi fronted as part of his Google Summer Of Code 
project:

Reimplement lldb-mi on top of the LLDB public SB API
https://summerofcode.withgoogle.com/projects/#5427847301169152

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

Re: [lldb-dev] FileSpec and normalization questions

[Pavel Labath via lldb-dev]

The llvm patches have been posted as: , <
https://reviews.llvm.org/D45942>.
On Fri, 20 Apr 2018 at 22:12, Greg Clayton  wrote:



> > On Apr 20, 2018, at 12:17 PM, Pavel Labath  wrote:
> >
> > On Fri, 20 Apr 2018 at 17:14, Greg Clayton  wrote:
> >>> On Apr 20, 2018, at 1:08 AM, Pavel Labath  wrote:
> >>>
> >>>
> >>> So, I can see the case for both, and I don't really have a clear
> >>> preference. All I would say is, whichever way we choose, we should
make
> > it
> >>> very explicit so that the users of FileSpec know what to expect.
> >
> >> I would say that without a directory it is a wildcard match on base
name
> > alone, and with one, the partial directories must match if the path is
> > relative, and the full directory must match if absolute. I will submit a
> > patch that keeps leading "./" and "../" during normalization and we will
> > see what people think.

> I have that as part of my current patch, so don't worry about that.
> >
> > Ok, what about multiple leading "./" components? Would it make sense to
> > collapse those to a single one ("././././foo.cpp" -> "./foo.cpp")?

> yes!

> >
> >
> >>>
> >>> On Thu, 19 Apr 2018 at 19:37, Zachary Turner via lldb-dev <
> >>> lldb-dev@lists.llvm.org> wrote:
>  I think I might have tried to replace some of the low level functions
> > in
> >>> FileSpec with the LLVM equivalents and gotten a few test failures,
but I
> >>> didn't have time to investigate.  It would be a worthwhile experiment
> > for
> >>> someone to try again if they have some cycles.
> >
> >> I took a look at the llvm file stuff and it has
llvm::sys::fs::real_path
> > which always resolves symlinks _and_ normalizes the path. Would be nice
to
> > break it out into two parts by adding llvm::sys::fs::normalize_path and
> > have llvm::sys::fs::real_path call it.
> >
> >>> I can try to take a look at it. The way I remember it, I just copied
> > these
> >>> functions from llvm and replaced all #ifdefs with runtime checks,
which
> > is
> >>> pretty much what you later did in llvm proper. Unless there has been
> > some
> >>> significant divergence since then, it shouldn't be hard to reconcile
> > these.
> >
> > So, I tried playing around with unifying the two implementations today.
I
> > didn't touch the normalization code, I just wanted to try to replace
path
> > parsing functions with the llvm ones.
> >
> > In theory, it should be as simple as replacing our parsing code in
> > FileSpec::SetFile with calls to llvm::sys::path::filename and
> > ...::parent_path (to set m_filename and m_directory).
> >
> > It turned out this was not as simple, and the reason is that the llvm
path
> > api's aren't completely self-consistent either. For example, for "//",
the
> > filename+parent_path functions will decompose it into "." and "", while
the
> > path iterator api will just report a single component ("//").
> >
> > After a couple of hours of fiddling with +/- ones, I think I have came
up
> > with a working and consistent implementation, but I haven't managed to
> > finish polishing it today. I'll try to upload the llvm part of the
patch on
> > Monday. (I'll refrain from touching the lldb code for now, to avoid
> > interfering with your patch).

> Sounds good. Feel free to replace my changes with LLVM stuff as long as
our test suite passes as I am adding a bunch of tests to cover all the
cases.

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

Re: [lldb-dev] r329889 - Use in-tree dsymutil on Darwin

[Jonas Devlieghere via lldb-dev]

Hi Ted,

I tried to reproduce this issue over the weekend on a Linux machine, but to no 
success. 

> On Apr 20, 2018, at 4:46 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> r329889 says "Use in-tree dsymutil on Darwin", but it's got these change in
> test/CMakeLists.txt:
> -set(LLDB_TEST_DEPS lldb)
> +set(LLDB_TEST_DEPS lldb dsymutil)
> 
> ...
> 
> +  --dsymutil $
> 
> 
> These changes aren't gated by a check for Darwin, so they happen on all
> systems. On my machine (Ubuntu 14), which doesn't have dsymutil, cmake
> generation gives errors about missing dependency dsymutil.

As dsymutil is an LLVM target, it should be available regardless of the host 
machine. That is, as Pavel noted, unless you’re doing a standalone build. Any 
chance this is the case? 

> CMake Error at tools/lldb/test/CMakeLists.txt:161 (add_dependencies):
>   The dependency target "dsymutil" of target "lldb-dotest" does not exist.
> 
> Jonas, can you gate those changes with a check for Darwin, which is the
> intention of the patch?

I’ve changed the configuration to only add the dependency when not doing a 
stand-alone built in r330568. Please let me know if that works for you. 

> 
> Ted
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

...

> On Apr 23, 2018, at 9:32 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On Fri, 20 Apr 2018 at 16:46, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> 
>> r329889 says "Use in-tree dsymutil on Darwin", but it's got these change
> in
>> test/CMakeLists.txt:
>> -set(LLDB_TEST_DEPS lldb)
>> +set(LLDB_TEST_DEPS lldb dsymutil)
> 
> Shouldn't this just be llvm-dsymutil, which should be always present
> (except standalone builds, I guess)?

I renamed llvm-dsymutil to just dsymutil a while ago because we’ve upstreamed 
almost everything (only support for BCSymbolMaps is missing, which I’m in the 
progress of upstreaming). 

> ___
> 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] r329889 - Use in-tree dsymutil on Darwin

[Pavel Labath via lldb-dev]

On Fri, 20 Apr 2018 at 16:46, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> r329889 says "Use in-tree dsymutil on Darwin", but it's got these change
in
> test/CMakeLists.txt:
> -set(LLDB_TEST_DEPS lldb)
> +set(LLDB_TEST_DEPS lldb dsymutil)

Shouldn't this just be llvm-dsymutil, which should be always present
(except standalone builds, I guess)?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev