> On Aug 27, 2015, at 4:17 PM, via lldb-dev wrote:
>
> Hi all,
>
> The question of how to tackle filename/path issues in a cross-platform
> environment arose as a result of http://reviews.llvm.org/D12115, and we would
> like to continue that discussion here. I'll start with excerpts from comme
On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote:
> 3.7.0-rc4 has just been tagged. It is identical to rc3, plus:
>
> - r245902: Revert r245355: change of clang-tools-extra symlink in the
> release script
> - r245947: Merge of r245927: Fix LLDB build on MIPS
> - r245948: Deprecate the DataLayo
Hi all,
The question of how to tackle filename/path issues in a cross-platform
environment arose as a result of http://reviews.llvm.org/D12115, and we would
like to continue that discussion here. I'll start with excerpts from comments
in that review to give you some background:
zturner:
[...
On Thu, Aug 27, 2015 at 10:17:24PM +, Zachary Turner wrote:
> In what instances do you think it wouldn't work? At least on Windows it's
> trivial. Jim provided some code that would work on OSX, and someone else
> provided a method earlier in the thread that should work for Linux. What
> are
In what instances do you think it wouldn't work? At least on Windows it's
trivial. Jim provided some code that would work on OSX, and someone else
provided a method earlier in the thread that should work for Linux. What
are the specific reliability concerns you have?
Changing lldb to prever deb
On Thu, Aug 27, 2015 at 05:05:23PM +, Zachary Turner via lldb-dev wrote:
> Well I'm xfailing it for now, but this other method seems kind of hackish
> to me because it means the inferior and the debugger have to coordinate
> with each other, which means the test has to know about the executable
https://llvm.org/bugs/show_bug.cgi?id=24600
Bug ID: 24600
Summary: TestHelloWorld can't get a valid callstack after
attaching
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status
Well I'm xfailing it for now, but this other method seems kind of hackish
to me because it means the inferior and the debugger have to coordinate
with each other, which means the test has to know about the executable and
the executable has to know about the test. I'd rather remove one direction
of
> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
> Of Hans Wennborg
> Sent: 27 August 2015 15:51
> To: Daniel Sanders
> Cc: cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; openmp-
> d...@lists.llvm.org; Dimitry Andric; Nikola Smiljanić; Sylvestre Le
Ah yes, our old friend TestHelloWorld. This guy definitely needs to be
fixed. I haven't actually looked at the code before to see why it was
so flaky, but now it all makes sense
I would just use the "usual" protocol of "expr release_child = 1"
here, but if you wanna go crazy, then go ahead...
It's not that it relies on a specific thread being selected, because as you
can see there are 2 threads in that trace. The problem is that the second
frame is not even yet in the main function, it's in the startup code
because of how early the attach process happens (which itsels is probably
actua
On Thu, Aug 27, 2015 at 6:43 AM, Daniel Sanders
wrote:
>> Please build and test. If no new issues arise, I plan to tag this as
>> 'final' tomorrow or Friday so we can ship the release next week.
>
> I'm afraid I can't build and test that quickly with the equipment I have at
> the moment. The litt
> Please build and test. If no new issues arise, I plan to tag this as
> 'final' tomorrow or Friday so we can ship the release next week.
I'm afraid I can't build and test that quickly with the equipment I have at the
moment. The little endian build is running on machine that was designed to be a
On Thursday, August 27, 2015 07:43 AM, Hans Wennborg wrote:
Dear testers,
3.7.0-rc4 has just been tagged. It is identical to rc3, plus:
Please build and test. If no new issues arise, I plan to tag this as
'final' tomorrow or Friday so we can ship the release next week.
Tests seem fine (except
The main issue I see with all these APIs is that they are
non-blocking. That is, the test executable cannot simply say "wait
until a debugger attaches", but it will have to do something like:
while (! attached) {
sleep(X);
attached = figure_out_if_i_am_attached_using_architecture_specific_metho
15 matches
Mail list logo
