On Wednesday, February 24, 2016 05:51 AM, Hans Wennborg via
Release-testers wrote:
Dear testers,
Release Candidate 3 has just been tagged [1]. Please build, test, and
upload to the sftp.
Uploaded:
clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ub
Hi lldb-dev,
I'm trying to write some tooling to help with debugging complex builds on Mac.
The libraries all have debugging info separated into .dSYM/ directories. Due
to some complexities in our build system, the .dSYM directories with the
debugging info have completely different base path
I added this to ResolveConstantValue():
case Value::FunctionVal:
if (const Function *constant_func = dyn_cast(constant))
{
value = 0;
return true;
}
break;
value is an APInt &, so it won’t take nul
Yes, the process listener is a little bit special.
When you are running a process in the debugger, the process is likely going to
be stopping and starting for all sorts of reasons. For instance, stepping
through a source line is actually going to:
step over the breakpoint at the start pc - i
Not sure. First off, you don't need to do:
process.GetBroadcaster().AddListener(...)
The debugger's listener is already listening to all the events. If you don't
specify a listener during launch the process will use the debugger's listener
automatically. If you end up making your own process li
I am still getting "non determinism".
This is my current code:
SBListener listener = debugger.GetListener();
process.GetBroadcaster().AddListener(listener,
SBProcess::eBroadcastBitStateChanged |
SBProcess::eBroadcastBitSTDO
I should clarify: it’s expected that there is a FunctionVal there. This is
much better when JITting later on, and the transform from FunctionVal to a
function pointer was a hack in IRForTarget.
The IRInterpreter just has to handle FunctionVals, as I just outlined.
Sean
> On Feb 24, 2016, at 2:
I think I understand what’s going on. The IR interpreter does this
[IRInterpreter.cpp:1573]:
–
// Find the address of the callee function
lldb_private::Scalar I;
const llvm::Value *val = call_inst->getCalledValue();
if (!frame.Evalu
I did some digging and found where the ID is being changed from 0x5 to 0xa in
the original code.
IRForTarget::runOnModule() calls ResolveFunctionPointers(), which gets a
Constant * from BuildFunctionPointer(). This Value has an ID of 0xa, and
runOnModule() then calls the original Function’s
On 23 Feb 2016, at 22:51, Hans Wennborg via Release-testers
wrote:
>
> Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.
Built and tested just fine on FreeBSD 10. Uploaded the following tarballs:
SHA256 (clang+llvm-3.8.0-rc3-amd64-unknown-freebsd10.ta
On 23 February 2016 at 21:51, Hans Wennborg via cfe-dev
wrote:
> Dear testers,
>
> Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.
Uploaded and tested for ARM and AArch64, all good.
Remember, this is *not* using a new Linux, so the GCC 5 issue doesn't
Here is the fixed code:
SBListener listener = debugger.GetListener();
SBLaunchInfo launch_info(args);
launch_info.SetEnvironmentEntries(env, true);
launch_info.SetWorkingDirectory("/home/dev/helloWorld");
SBProcess process = target.Launch(launch_info, error);
process.GetBroadcaster().AddListene
On Tue, Feb 23, 2016 at 8:51 PM, Ben Pope wrote:
> On Wednesday, February 24, 2016 05:51 AM, Hans Wennborg via Release-testers
> wrote:
>>
>> Dear testers,
>>
>> Release Candidate 3 has just been tagged [1]. Please build, test, and
>> upload to the sftp.
>
>
> On Ubuntu 15.10 x86_64 I got:
>
> Fai
On Tue, Feb 23, 2016 at 1:51 PM, Hans Wennborg wrote:
> Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.
Windows (sha1):
76f8f91debd2e101b9adc4a6f2230fcd5e18bb5c LLVM-3.8.0-rc3-win32.exe
b87654327d3ae537f8afec06ea0fa63121b9a86e LLVM-3.8.0-rc3-win64.exe
> I don't know *exactly* how you're building this or which OS or hw..
Renato said: "errors while building OpenMP on my AArch64 box"
So this is AARCH64, which is ARM 64 bit. Although I think Intel manufactures
some of those
(see the top end Altera FPGAs), we don’t have any to play with in the Op
Thank you very much for that detailed description on explaining the 'basics'.
I got it working so far but there is a small issue with the code I am currently
running. When the main loop (there is only one) receives a breakpoint event and
I am trying to get the thread description (After the brea
That reply doesn't help identify the problem at all. The Intel people should
know the code causing this. I do a nightly build on aarch64 every day against
ToT and don't see a problem.
Original Message
From: Cownie, James H
Sent: Wednesday, February 24, 2016 23:40
To: cbergst...@pathscale.c
I don't know *exactly* how you're building this or which OS or hw.. I don't see
these problems so will need more details. The Intel guys may know the perl
scripts better than me.. I don't really see how those can be the root of the
problem.
Is there an open issue for this?
Original Message
On 8 February 2016 at 22:56, wrote:
> Imho it's critical to get parallel programming working on ARMv8 ( even if
> it's crappy OMP) to start. Please enable it and I'll run the tests against
> our internal QA and we can informally handle testing / guarding against
> regressions.
So, I got some
I completely agree with you that we shouldn't change LLDB too much just to
speed up the startup time at the first use.
For android we already have a host side disk cache in place similar to what
you described for iOS and we already using ADB (an android specific
interface) to download the files fr
This is a known bug (bugzilla is slugish right now, so I can't look up
the number). The stopped event does not seem to get through most of
the times, although the stop is actually performed. I am afraid I
can't offer any workaround for the time being...
On 24 February 2016 at 07:36, Jeffrey.fudan
21 matches
Mail list logo
