We'll be at Tied House as usual, starting on Thursday the 3rd at 7pm!
If you can, help us plan and RSVP here: http://meetu.ps/2RP12T
See everyone there!
- George
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
On Mar 1, 2016, at 11:45 AM, Zachary Turner wrote:
>
> Alright I think i get it. Basically terminal entry means "everything from
> this address onwards is not part of any function"
Yes
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llv
Alright I think i get it. Basically terminal entry means "everything from
this address onwards is not part of any function"
On Tue, Mar 1, 2016 at 11:36 AM Greg Clayton wrote:
>
> > On Mar 1, 2016, at 11:30 AM, Zachary Turner wrote:
> >
> > We do know the last line of a function. In the review i
> On Mar 1, 2016, at 11:30 AM, Zachary Turner wrote:
>
> We do know the last line of a function. In the review i posted, you can see
> the condition where i set is_epilogue to true. That is the last line of a
> function corresponding to the } (although the function may contain additional
> by
We do know the last line of a function. In the review i posted, you can see
the condition where i set is_epilogue to true. That is the last line of a
function corresponding to the } (although the function may contain
additional bytes, since that only refers to the first byte of the epilogue.
But I
https://llvm.org/bugs/show_bug.cgi?id=26790
Bug ID: 26790
Summary: IRForTarget
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
C
> On Feb 29, 2016, at 11:02 PM, Jeffrey Tan wrote:
>
> My assumption is that different sections of the binary will be mapped
> continuously in memory; and the first section(which should be a header
> section for the binary) will stands for the base address of the whole module.
> Is this assum
> On Feb 29, 2016, at 5:51 PM, Zachary Turner wrote:
>
>
>
> On Mon, Feb 29, 2016 at 5:49 PM Zachary Turner wrote:
> Those are addresses. Here's the situation I was encountering this on:
>
> // foo.h
> #include "bar.h"
> inline int f(int n)
> {
> return g(n) + 1;
> }
>
> // bar.h
> inl
Hi,
Thanks for the report. I've had my eye set on this for a while, but
unfortunately it hasn't gotten to the top of the list yet. The main
reasons i was slow to respond are:
- there is no test included.
- I am not entirely sure about the proposed solution. It looks a bit
hackish (the stop reason
Hi and thank you for the detailed reply, Tamas.
Ok, so I’ll cope with increased size of lldb-server for AArch64.
As a side note – is there any publicly available roadmap for LLDB on Android,
that covers features to implement\issues to fix? I suggest that the community
will greatly appreciate to g
> > clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz
> > My machine died during the check-all stage and disappeared from the
> network. I've fixed it and am currently running the last few bits of test-
> release.sh manually.
>
> Thanks, let me know how this turns out.
>
> So far, it sounds li
As Pavel mentioned the unreasonable large size for lldb-server is caused by
the fact that we are relying on the liker to remove the unused code and it
can't do too good job because we have lot of unreasonable dependencies.
The size difference between arm and arrahc64 caused by several reason:
* On
Thank you for the quick reply, Pavel.
Unfortunately, addition of -DLLVM_TARGETS_TO_BUILD=AArch64 to my cmake
configuration hasn't reduced the size of resulting binary on a single byte.
-Original Message-
From: Pavel Labath [mailto:lab...@google.com]
Sent: Tuesday, March 1, 2016 12:18 PM
Hi,
so the problem here is that we are currently relying on the linker to
remove code that we don't need, and it can't always do a good job in
figuring out which code is not used due to complex dependencies. So,
innocent-looking changes in the code can pull in lots of transitive
dependencies, even
14 matches
Mail list logo
