> 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 Windows
> machine an
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
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
n
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 t
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
> 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 for lldb. But maybe they have gotten
> more g
> 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, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
wrote:
>>
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 on
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 woul
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 path normalization function
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 '/' characters. I would like
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 solve
>
> 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
> 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 lldb developers,
>>>
>>> I've been researching using lldb + gdbserve
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 you trying to test? I
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,
> 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 on Harvard
>> architecture with multiple address
>
> 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, 201
> 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 it, in a darwin world
> 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 adopted approach is that everyt
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 alread
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, which are
> very close to
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 t
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 th
24 matches
Mail list logo
