Sure, sounds good!
Very happy somebody is taking this over (I bootstrapped/prototyped it at
the time because I wanted to check feasability of good debugging support
for this C#=>LLVM project I was planning to start:
https://github.com/xen2/SharpLang ).
Adding windows build bot was also something I
I'm actually starting to work on this now because it's the next thing
causing tests to fail for me whiel I try to get the test suite working.
Some of the changes I've made conflict with yours on a fundamental level,
so I'm working through your patch and trying to incorporate the stuff you
did in a
It's getting there. I know of only 4 issues with the test suite currently
that I'm working on fixing. There might be more, but when I run "ninja
check-lldb" these are the only ones that happen. They are, in no
particular order:
PutSTDIN doesn't work right (may have been fixed due to a recent p
Also, once it's working, I plan to set up a Windows build bot that's
connected to the main llvm waterfall, and have it run automatically each
time a new patch is submitted, similar to how the build bots work for the
other platform. That's my ultimate goal, just making sure that if the
build breaks
Zachary Turner schreef op 21-10-2014 om 21:24:
Thanks for the response. I definitely think it would be great to have
this functionality in. Originally when I started working on LLDB my
goal was just to get the test suite up and running 100% (even if all the
tests don't pass, at least the test
Thanks for the response. I definitely think it would be great to have this
functionality in. Originally when I started working on LLDB my goal was
just to get the test suite up and running 100% (even if all the tests don't
pass, at least the test infrastructure would run tests and correctly repor
Sorry for answering much later (was dragged into other LLVM subprojects
recently), but figured I better get this merged before it diverges too much
and get lost... (to avoid someone ending up reimplementing everything again
from scratch).
Anyway, the biggest part of this branch was this commit:
ht
You are welcome to try to upstream some of your work, but given the work
I've done on refactoring the codebase, it might be difficult to do a
straight rebase of your fork onto tip. Instead of a rebase, which would
force difficult merges at numerous points, perhaps easier would be to sync
to tip an
Hey Virgile,
I think you'll need to talk to Zach for this. There has been quite a lot
of changes, and I think some of the changes may impact significantly on
your merge.
I'm not up to date with all of the changes now in trunk, so best to ask
him. I could be wrong and it be easy :)
Colin
I suppose I should merge my branch back to LLDB trunk at some point?
I could rebase & merge the new ProcessWindows and DynamicLoaderWindows
plugins (
https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532)
and keep the other LLDB changes aside for now if they need further
disc
On Mon, Jun 16, 2014 at 9:12 PM, Greg Clayton wrote:
>
> > On Jun 14, 2014, at 3:12 AM, Eran Ifrah wrote:
> >
> > Hi,
> >
> > I tried both building lldb with MSVC and with MinGW both failed to debug
> native Windows executables (I actually tried 3 types of executables, 1
> built with MinGW, 1 wi
> On Jun 14, 2014, at 3:12 AM, Eran Ifrah wrote:
>
> Hi,
>
> I tried both building lldb with MSVC and with MinGW both failed to debug
> native Windows executables (I actually tried 3 types of executables, 1 built
> with MinGW, 1 with clang 3.4 and 1 with Visual Studio)
>
> This is the error
Hi Eran,
Windows is not supported as a target platform on ToT.
Virgile Bello has a branch on his github account
(https://github.com/xen2/lldb/tree/msvc12) which does, though. Ive tried
it with small gcc-built dwarf2 debug binaries. It works enough to stop
at breakpoints, stepping, viewing the
Hi Todd,
Seems like accidently I've started off-topic here. The guy asked about
Windows while I'm more into Linux and I brought my issues only due to
obvious similarities.
For sure the Linux support is really just x86_64 and x86 32-bit to some
extent, and not other architectures.
It's ver
Hi Eran,
I got the same when I try to debug a _Linux_ application on Linux running
on non-PC CPU. Seems like only 'MacOSX and Linux' on 'i686 and x86_64' are
properly supported. Problem was already described in the
message here: http://comments.gmane.org/gmane.comp.debugging.lldb.devel/3530
Hi Eran,
I got the same when I try to debug a _Linux_ application on Linux running on
non-PC CPU. Seems like only 'MacOSX and Linux' on 'i686 and x86_64' are
properly supported. Problem was already described in the message here:
http://comments.gmane.org/gmane.comp.debugging.lldb.devel/3530
Hi,
I tried both building lldb with MSVC and with MinGW both failed to debug
native Windows executables (I actually tried 3 types of executables, 1
built with MinGW, 1 with clang 3.4 and 1 with Visual Studio)
This is the error I am getting:
$ lldb D:/src/TestArea/ClangVC/Debug/ClangVC.exe
error:
17 matches
Mail list logo
