Re: [lldb-dev] Making a new symbol provider

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

Re: [lldb-dev] Making a new symbol provider

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

Re: [lldb-dev] Questions for module/symbol load/unload events

> 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

Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged

> > 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

Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb

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: *

Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb

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

Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb

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,