> -Original Message-
> From: Daniel Sanders
> Sent: 06 March 2016 16:57
> To: Hans Wennborg; Release-testers
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: RE: [Release-testers] [3.8 Release] 'final' has been tagged
>
> Uploaded the following:
> 3d6cb2
On Wed, Mar 2, 2016 at 4:33 PM, Hans Wennborg wrote:
> Please build the final binaries and upload to the sftp.
Mac and Windows uploaded (sha1sum):
8d1f41aee5f3b29f14db90141430faee5e0d7723
clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
f30de7ee8006dc779064202bcc345c418c1ac249 LLVM-3.8.0-win32.exe
32
> On Mar 4, 2016, at 8:08 AM, Paul Peet via lldb-dev
> wrote:
>
> Hi Pavel,
>
> First of all, thank you for looking into this. I really appreciate it.
> Secondly, the check with GetRestartedFromEvent did the trick.
> I am finally getting correct information. Thank You very much.
I would like
Not sure why we aren't treating this as a relative path. Probably because of
the 1000 '/' characters. Feel free to dig into lldb_private::FileSpec and play
around and see where things are going wrong.
You can probably fix LLDB, when it resolves paths, to clean this up, but we
typically don't re
I was planning to take a stab at writing documentation, since I just
finished my own C++ app on top of lldb. (Code Medic)
Attached is my attempt to add docs to SBAddress. Am I on the right track?
If so, I'll tackle additional files.
Thanks,
John
On Mon, Mar 7, 2016 at 10:56 AM, Greg Clayton vi
This discussion originally started on a code review thread, but I figured I
would continue it here since the patch has landed and I want to do more
work as a followup.
So LLDB's LineTable data structures have the notion of a "terminal entry".
As I understand it, LineTables are structured as a sequ
> On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev
> wrote:
>
> This discussion originally started on a code review thread, but I figured I
> would continue it here since the patch has landed and I want to do more work
> as a followup.
>
> So LLDB's LineTable data structures have the
Does DWARF not store this information? Because it seems like it could be
efficiently stored in an interval tree, the question is just whether it is
efficient to convert what DWARF stores into that format.
PDB returns line entries in the format I described, with a start address
and a byte length,
The one thing that might confuse you is we actually store line entries using
lldb_private::LineTable::Entry structures which do not have the byte size or
the file as a FileSpec:
class LineTable {
protected:
struct Entry
{
lldb::addr_t file_addr; ///< The file address
> On Mar 7, 2016, at 3:21 PM, Zachary Turner wrote:
>
> Does DWARF not store this information? Because it seems like it could be
> efficiently stored in an interval tree, the question is just whether it is
> efficient to convert what DWARF stores into that format.
No it stores it just like w
Hi Greg,
I am not sure if I understand the behavior here: the long relative file
path from our build system does *not* exist on file system, do you mean
lldb will always try to resolve this relative path to a *real* file on file
system using stat() call? And it will fail to bind the breakpoint if
> On Mar 7, 2016, at 4:08 PM, Jeffrey Tan wrote:
>
> Hi Greg,
>
> I am not sure if I understand the behavior here: the long relative file path
> from our build system does *not* exist on file system, do you mean lldb will
> always try to resolve this relative path to a *real* file on file sys
Thanks for the info, I will debug this.
One more quick question related to this: in full path breakpoint case(IDE
scenario), do we compare both file name and directory path exact match and
bind breakpoint successfully? I ask this because of the breakpoint issue I
found:
1. I have a symbolic link fo
Apologies for the delay, ARM and AArch64 tested and uploaded!
--renato
On 3 March 2016 at 07:33, Hans Wennborg via lldb-dev
wrote:
> Dear testers,
>
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>
> Please b
CentOS 6 uploaded and tested.
05141a39af0998770e4bf1953980a10f69aca450
clang+llvm-3.8.0-linux-x86_64-centos6.tar.xz
On Wed, Mar 2, 2016 at 6:33 PM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:
> Dear testers,
>
> My list of blockers is empty, and there were no new
15 matches
Mail list logo
