Re: [lldb-dev] FileSpec and normalization questions

> On Apr 19, 2018, at 11:33 AM, Jim Ingham wrote: > > I can't see any reason why we benefit from having these differently spelled > equivalent paths floating around. You want to be careful to preserve the > path syntax, since it would be weird to be cross debugging to a

Re: [lldb-dev] Proposal: Using LLD in tests

Our Windows buildbots use msys for gnuisms. The makefiles in the test suite run fine with minimal modifications (just the object delete hack Zach put in to use del instead of rm; msys make doesn't accept cmd syntax while Cygwin make does). Now, that's using clang to build Hexagon binaries, but

Re: [lldb-dev] FileSpec and normalization questions

We actually use it in some places, but it's limited. Before I did that was when I added the PathSyntax to FileSpec which essentially servers the same purpose. We could in theory drop PathSyntax now that LLVM supports all of the same functionality. It's a pretty invasive refactor though which I

Re: [lldb-dev] FileSpec and normalization questions

I can't see any reason why we benefit from having these differently spelled equivalent paths floating around. You want to be careful to preserve the path syntax, since it would be weird to be cross debugging to a Windows machine and have to type Posix paths. But other than that, removing all

Re: [lldb-dev] Advice on architectures with multiple address spaces

Hexagon has a single address space, so we don't need to do anything like this. When I worked on Motorola 56xxx DSPs we had memory spaces, but we didn't use RSP. We had our own protocol that used a struct for addreses, with the space (an enum, defined per supported core) and a uint32_t (later 2

Re: [lldb-dev] FileSpec and normalization questions

> On Apr 19, 2018, at 11:21 AM, Zachary Turner wrote: > > > > On Thu, Apr 19, 2018 at 11:19 AM Jim Ingham via lldb-dev > wrote: > The last time I looked at the llvm functions they only support the path > syntax of the llvm host, which won't do

Re: [lldb-dev] Advice on architectures with multiple address spaces

> On Apr 19, 2018, at 10:54 AM, Greg Clayton wrote: > > > >> On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote: >> >> >> >>> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev >>> wrote: >>> >>> >>> On Apr 19,

Re: [lldb-dev] FileSpec and normalization questions

On Thu, Apr 19, 2018 at 11:19 AM Jim Ingham via lldb-dev < lldb-dev@lists.llvm.org> wrote: > The last time I looked at the llvm functions they only support the path > syntax of the llvm host, which won't do for lldb. But maybe they have > gotten more general recently? > > Yes in fact I was the

Re: [lldb-dev] FileSpec and normalization questions

On Thu, Apr 19, 2018 at 11:14 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > Also, looking at the tests for normalizing paths I found the following > pairs of pre-normalized and post-normalization paths for posix: > > {"//", "//"}, > {"//net", "//net"}, > > Why

Re: [lldb-dev] FileSpec and normalization questions

The last time I looked at the llvm functions they only support the path syntax of the llvm host, which won't do for lldb. But maybe they have gotten more general recently? Jim > On Apr 19, 2018, at 11:16 AM, Davide Italiano via lldb-dev > wrote: > > IIRC We have

Re: [lldb-dev] FileSpec and normalization questions

IIRC We have path normalization functions in llvm, have you looked at them? Thanks, -- Davide On Thu, Apr 19, 2018 at 11:14 AM, Greg Clayton via lldb-dev wrote: > We currently have DWARF that has a DW_AT_comp_dir that is set to "./" > followed by any number of extra

[lldb-dev] FileSpec and normalization questions

We currently have DWARF that has a DW_AT_comp_dir that is set to "./" followed by any number of extra '/' characters. I would like to have this path normalized as we parse the DWARF so we don't end up with line tables with a variety of ".//+" prefixes on each source file. While looking to

Re: [lldb-dev] Proposal: Using LLD in tests

> > we have some good coverage there that our PDBs are "as good as" Microsoft > PDBs, and in the future we have plans to have a debug info test suite that > tests LLD-generated PDBs with Microsoft debuggers. > Thanks Zach. What I was asking is exactly the other half of this equation. Testing LLDB

Re: [lldb-dev] Advice on architectures with multiple address spaces

> On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote: > > > >> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev >> wrote: >> >> >> >>> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev >>> wrote: >>> >>> Hi

Re: [lldb-dev] Proposal: Using LLD in tests

On Thu, 19 Apr 2018 at 18:19, Leonard Mosescu wrote: >>the PDB tests under lit/SymbolFile/PDB need a linker to produce the program database > With this proposal, would we preserve any coverage for MSVC produced debug information? Well.. the question there is what are

Re: [lldb-dev] Proposal: Using LLD in tests

We already don't really have any. All of the makefiles that build the inferiors use a gcc style command line syntax, and the way we made that work on Windows is to use clang for the compiler. So MSVC is already out of the equation. There may be one or two instances where we check in a PDB file,

Re: [lldb-dev] Advice on architectures with multiple address spaces

> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev > wrote: > > > >> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev >> wrote: >> >> Hi lldb developers, >> >> I've been researching using lldb + gdbserver stub that is based

Re: [lldb-dev] Proposal: Using LLD in tests

> > the PDB tests under lit/SymbolFile/PDB need a linker to produce the program > database With this proposal, would we preserve any coverage for MSVC produced debug information? On Thu, Apr 19, 2018 at 9:47 AM, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > > On Apr 19,

Re: [lldb-dev] Proposal: Using LLD in tests

> On Apr 19, 2018, at 9:39 AM, Pavel Labath wrote: > > Yes, I considered the lld+Mach-O situation. I understand that it does not > work very well, but I don't know what exactly that means. > > However, I am not sure that we even need a linker for Mach-O. As I > understand

Re: [lldb-dev] Advice on architectures with multiple address spaces

> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev > wrote: > > Hi lldb developers, > > I've been researching using lldb + gdbserver stub that is based on Harvard > architecture with multiple address spaces (one program, multiple data). The > commonly

Re: [lldb-dev] Proposal: Using LLD in tests

Yes, I considered the lld+Mach-O situation. I understand that it does not work very well, but I don't know what exactly that means. However, I am not sure that we even need a linker for Mach-O. As I understand it, in a darwin world, the linker does not even touch the debug info, and lldb is

Re: [lldb-dev] Proposal: Using LLD in tests

The last I knew LLD doesn't work on mach-o very well, so be sure to not require LLD for linking any Darwin executables. > On Apr 19, 2018, at 6:42 AM, Pavel Labath via lldb-dev > wrote: > > Hello all, > > currently we have a couple of tests, in-tree or under review,

[lldb-dev] Advice on architectures with multiple address spaces

Hi lldb developers, I've been researching using lldb + gdbserver stub that is based on Harvard architecture with multiple address spaces (one program, multiple data). The commonly adopted approach is that everything is mapped to a single "virtual" address space. The stub reads/writes from/to

[lldb-dev] Proposal: Using LLD in tests

Hello all, currently we have a couple of tests, in-tree or under review, which are very close to being host-independent. The only part they are missing is the ability to link a intermediate object file: - the ppc64 test in https://reviews.llvm.org/D44437 needs a linker to resolve relocations in