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

[Pavel Labath via lldb-dev]

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 though they are not used. I suspect something like
that is going on here, although we should keep in mind that arm64 code
is less dense naturally. Any help on this front will be welcome,
although it probably won't be trivial, as we have probably picked off
the low-hanging fruit already.

That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to
your cmake line. We use that, although I can't say how much it affects
the size of the resulting binary.

help that helps,
pl

On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev
 wrote:
> Hello, fellow developers and congratulations with long awaited 3.8 Release.
>
> I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release] 
> RC3 source is so much bigger than its ARM counterpart.
> See the numbers:
> 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
>  9570916 Feb 29 22:23 lldb-server-3.8.0-arm
> lldb-server-3.8.0-aarch64: ELF 64-bit LSB  executable, ARM aarch64, version 1 
> (SYSV), statically linked, stripped
> lldb-server-3.8.0-arm: ELF 32-bit LSB  executable, ARM, EABI5 version 1 
> (SYSV), statically linked, stripped
>
> My build configuration is MinSizeRel in both cases:
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
> -DANDROID_ABI=aarch64
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=aarch64
> -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
> -DANDROID_ABI=armeabi
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=arm
> -DLLVM_HOST_TRIPLE=arm-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> Maybe I need some additional settings to be set for AArch64 case?
>
> Regards,
> Mikhail
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans 
> Wennborg via lldb-dev
> Sent: Wednesday, February 24, 2016 12:51 AM
> To: release-test...@lists.llvm.org
> Cc: llvm-dev ; cfe-dev ; 
> openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 
> 
> Subject: [lldb-dev] [3.8 Release] RC3 has been tagged
>
> Dear testers,
>
> Release Candidate 3 has just been tagged [1]. Please build, test, and upload 
> to the sftp.
>
> If there are no regressions from previous release candidates, this will be 
> the last release candidate before the final release.
>
> Release notes can still go into the branch.
>
> Thanks again for all your work!
> Hans
>
>  [1] 
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.  Any unauthorized review, use, disclosure or 
> distribution
> is prohibited.  If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Mikhail Filimonov via lldb-dev]

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
To: Mikhail Filimonov 
Cc: lldb-dev@lists.llvm.org
Subject: 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, even though 
they are not used. I suspect something like that is going on here, although we 
should keep in mind that arm64 code is less dense naturally. Any help on this 
front will be welcome, although it probably won't be trivial, as we have 
probably picked off the low-hanging fruit already.

That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to your 
cmake line. We use that, although I can't say how much it affects the size of 
the resulting binary.

help that helps,
pl

On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev 
 wrote:
> Hello, fellow developers and congratulations with long awaited 3.8 Release.
>
> I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release] 
> RC3 source is so much bigger than its ARM counterpart.
> See the numbers:
> 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
>  9570916 Feb 29 22:23 lldb-server-3.8.0-arm
> lldb-server-3.8.0-aarch64: ELF 64-bit LSB  executable, ARM aarch64, version 1 
> (SYSV), statically linked, stripped
> lldb-server-3.8.0-arm: ELF 32-bit LSB  executable, ARM, EABI5 version 1 
> (SYSV), statically linked, stripped
>
> My build configuration is MinSizeRel in both cases:
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git 
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
> -DANDROID_ABI=aarch64
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=aarch64
> -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git 
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
> -DANDROID_ABI=armeabi
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=arm
> -DLLVM_HOST_TRIPLE=arm-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> Maybe I need some additional settings to be set for AArch64 case?
>
> Regards,
> Mikhail
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of 
> Hans Wennborg via lldb-dev
> Sent: Wednesday, February 24, 2016 12:51 AM
> To: release-test...@lists.llvm.org
> Cc: llvm-dev ; cfe-dev 
> ; openmp-dev (openmp-...@lists.llvm.org) 
> ; LLDB Dev 
> Subject: [lldb-dev] [3.8 Release] RC3 has been tagged
>
> Dear testers,
>
> Release Candidate 3 has just been tagged [1]. Please build, test, and upload 
> to the sftp.
>
> If there are no regressions from previous release candidates, this will be 
> the last release candidate before the final release.
>
> Release notes can still go into the branch.
>
> Thanks again for all your work!
> Hans
>
>  [1] 
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/0098
> 66.html ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> --
> - This email message is for the sole use of the intended 
> recipient(s) and may contain confidential information.  Any 
> unauthorized review, use, disclosure or distribution is prohibited.  
> If you are not the intended recipient, please contact the sender by 
> reply email and destroy all copies of the original message.
> --
> - ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 arm we compile to thumb2 instruction set what is in average ~30%
smaller then the arm (and aarch64) instruction set. Before this change the
size of lldb-server on arm was ~14MB
* We have Safe ICF (identical code folding) enabled for arm what reduces
the binary size by 5-10%. It is not enabled for aarch64 because last time I
checked there was still some issue in ld.gold when using ICF on aarch64. It
should be already fixed upstream but haven't reached the NDK yet.
* The aarch64 lldb-server capable of debugging both arm and aarch64
applications so it contains a bit more code because of this (e.g. 2
spearate register context)

Optimizing the size of both binary is possible (and we want to do it sooner
or later) but because of the reasons I listed the arm one will stay much
smaller then the aarch64 one.

Tamas

On Tue, Mar 1, 2016 at 9:18 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> 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 though they are not used. I suspect something like
> that is going on here, although we should keep in mind that arm64 code
> is less dense naturally. Any help on this front will be welcome,
> although it probably won't be trivial, as we have probably picked off
> the low-hanging fruit already.
>
> That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to
> your cmake line. We use that, although I can't say how much it affects
> the size of the resulting binary.
>
> help that helps,
> pl
>
> On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev
>  wrote:
> > Hello, fellow developers and congratulations with long awaited 3.8
> Release.
> >
> > I wonder why AArch64 stripped binary of lldb-server built from [3.8
> Release] RC3 source is so much bigger than its ARM counterpart.
> > See the numbers:
> > 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
> >  9570916 Feb 29 22:23 lldb-server-3.8.0-arm
> > lldb-server-3.8.0-aarch64: ELF 64-bit LSB  executable, ARM aarch64,
> version 1 (SYSV), statically linked, stripped
> > lldb-server-3.8.0-arm: ELF 32-bit LSB  executable, ARM, EABI5
> version 1 (SYSV), statically linked, stripped
> >
> > My build configuration is MinSizeRel in both cases:
> > cmake -GNinja
> > -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> > -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> > -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
> > -DANDROID_ABI=aarch64
> > -DCMAKE_CXX_COMPILER_VERSION=4.9
> > -DLLVM_TARGET_ARCH=aarch64
> > -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
> > -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> > -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
> >
> > cmake -GNinja
> > -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> > -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> > -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
> > -DANDROID_ABI=armeabi
> > -DCMAKE_CXX_COMPILER_VERSION=4.9
> > -DLLVM_TARGET_ARCH=arm
> > -DLLVM_HOST_TRIPLE=arm-unknown-linux-android
> > -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> > -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
> >
> > Maybe I need some additional settings to be set for AArch64 case?
> >
> > Regards,
> > Mikhail
> >
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Hans Wennborg via lldb-dev
> > Sent: Wednesday, February 24, 2016 12:51 AM
> > To: release-test...@lists.llvm.org
> > Cc: llvm-dev ; cfe-dev ;
> openmp-dev (openmp-...@lists.llvm.org) ; LLDB
> Dev 
> > Subject: [lldb-dev] [3.8 Release] RC3 has been tagged
> >
> > Dear testers,
> >
> > Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.
> >
> > If there are no regressions from previous release candidates, this will
> be the last release candidate before the final release.
> >
> > Release notes can still go into the branch.
> >
> > Thanks again for all your work!
> > Hans
> >
> >  [1]
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> ---
> > This email message is for the sole use of the intended recipient(s) and
> may contain
> > confidential information.  Any unauthorized review, use, disclosure 

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

[Daniel Sanders via lldb-dev]

> > 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 like there are no new issues in rc3, so I'm hoping
> we can make that the final version for 3.8.0 real soon.
> 
> Cheers,
> Hans
> 

'check-all' is still killing the machine but I think I know what the problem 
is. While investigating some of the rc2 problems I noticed that g++-multilib 
wasn't installed and this was disabling the mips64el sanitizers. Installing 
this didn't cause problems at the time but I've noticed that some of the 
mips64el sanitizer tests are very memory hungry. I noticed several occasions 
where parallel asan tests were consuming ~200% of RAM and it would have been 
swapping heavily (on a USB2 disk) to cope. If later tests require even more RAM 
then it would explain why the system stops responding. I'm going to uninstall 
g++-multilib and rebuild rc3. Hopefully that will make check-all work again.

For now, I've commented out the check-all command and uploaded 
clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz (sha1sum: 
e280bf6db094a81f22f4cdf6c0b5955493a11b05). I'm going to run this through my 
usual test-suites and I should have the results by this evening.


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Mikhail Filimonov via lldb-dev]

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 get a glimpse on the direction of development for 
that target.

Regards,
Mikhail

From: Tamas Berghammer [mailto:tbergham...@google.com]
Sent: Tuesday, March 1, 2016 1:34 PM
To: Pavel Labath ; Mikhail Filimonov 
Cc: lldb-dev@lists.llvm.org
Subject: 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:
* On arm we compile to thumb2 instruction set what is in average ~30% smaller 
then the arm (and aarch64) instruction set. Before this change the size of 
lldb-server on arm was ~14MB
* We have Safe ICF (identical code folding) enabled for arm what reduces the 
binary size by 5-10%. It is not enabled for aarch64 because last time I checked 
there was still some issue in ld.gold when using ICF on aarch64. It should be 
already fixed upstream but haven't reached the NDK yet.
* The aarch64 lldb-server capable of debugging both arm and aarch64 
applications so it contains a bit more code because of this (e.g. 2 spearate 
register context)

Optimizing the size of both binary is possible (and we want to do it sooner or 
later) but because of the reasons I listed the arm one will stay much smaller 
then the aarch64 one.

Tamas

On Tue, Mar 1, 2016 at 9:18 AM Pavel Labath via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
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 though they are not used. I suspect something like
that is going on here, although we should keep in mind that arm64 code
is less dense naturally. Any help on this front will be welcome,
although it probably won't be trivial, as we have probably picked off
the low-hanging fruit already.

That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to
your cmake line. We use that, although I can't say how much it affects
the size of the resulting binary.

help that helps,
pl

On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
> Hello, fellow developers and congratulations with long awaited 3.8 Release.
>
> I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release] 
> RC3 source is so much bigger than its ARM counterpart.
> See the numbers:
> 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
>  9570916 Feb 29 22:23 lldb-server-3.8.0-arm
> lldb-server-3.8.0-aarch64: ELF 64-bit LSB  executable, ARM aarch64, version 1 
> (SYSV), statically linked, stripped
> lldb-server-3.8.0-arm: ELF 32-bit LSB  executable, ARM, EABI5 version 1 
> (SYSV), statically linked, stripped
>
> My build configuration is MinSizeRel in both cases:
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
> -DANDROID_ABI=aarch64
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=aarch64
> -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
> -DANDROID_ABI=armeabi
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=arm
> -DLLVM_HOST_TRIPLE=arm-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> Maybe I need some additional settings to be set for AArch64 case?
>
> Regards,
> Mikhail
>
> -Original Message-
> From: lldb-dev 
> [mailto:lldb-dev-boun...@lists.llvm.org]
>  On Behalf Of Hans Wennborg via lldb-dev
> Sent: Wednesday, February 24, 2016 12:51 AM
> To: release-test...@lists.llvm.org
> Cc: llvm-dev mailto:llvm-...@lists.llvm.org>>; 
> cfe-dev mailto:cfe-...@lists.llvm.org>>; openmp-dev 
> (openmp-...@lists.llvm.org) 
> mailto:openmp-...@lists.llvm.org>>; LLDB Dev 
> mailto:lldb-dev@lists.llvm.org>>
> Subject: [lldb-dev] [3.8 Release] RC3 has been tagged
>
> Dear testers,
>
> Release Candidate 3 has just been tagged [1]. Pl

Re: [lldb-dev] Problems with core load on Linux and proposed solution

[Pavel Labath via lldb-dev]

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 part) and I was hoping I could come up with a
cleaner solution...

So, for the thread id part, I'd be happy to commit that as soon as you
create a test (or you can wait until I create one at some point...).

For the stop reason, if you want to speed it up, you can try running
the patch by Jim Ingham, as he's the one who will have to approve that
anyway. (and please also add a test)

cheers,
pl


On 26 February 2016 at 16:58, Zachary Turner  wrote:
> Cced some people who work on Linux.
>
> Not sure how this slipped through the cracks, but sometimes you can have
> better results by just posting a patch to lldb-commits and ccing the right
> person (check owners file to find out who the right person is)
>
> On Thu, Feb 25, 2016 at 5:18 PM Eugene Birukov via lldb-dev
>  wrote:
>>
>> No response. I filed a bug, hopefully somebody will pay attention.
>>
>> https://llvm.org/bugs/show_bug.cgi?id=26322
>>
>>
>> 
>> From: mi...@microsoft.com
>> To: eugen...@hotmail.com; lldb-dev@lists.llvm.org
>> Subject: RE: Problems with core load on Linux and proposed solution
>> Date: Thu, 25 Feb 2016 22:37:45 +
>>
>>
>> Eugene, do you know if they have taken these changes? Have you heard from
>> anybody on lldb-dev?
>>
>>
>>
>> mikem
>>
>>
>>
>> From: Eugene Birukov [mailto:eugen...@hotmail.com]
>> Sent: Thursday, January 21, 2016 10:46 AM
>> To: LLDB 
>> Subject: Problems with core load on Linux and proposed solution
>>
>>
>>
>> Hi,
>>
>>
>>
>> LLDB 3.8 has much better support for core load on Linux than 3.7 - thanks
>> a lot! But there are still two problems.
>>
>>
>>
>> 1. The thread ID are lost and there is FIXME in the code
>>
>> 2. If core dump is obtained from live process (i.e. gdb attach, gcore,
>> detach) then there is no thread that has any reason to stop. LLDB hangs
>> forever on such a core.
>>
>>
>>
>> Here is the fix that works for me for both problems.
>>
>>
>>
>> Thanks,
>>
>> Eugene
>>
>>
>>
>> diff --git a/include/lldb/Target/Process.h b/include/lldb/Target/Process.h
>>
>> index 6bb7a3d..915ca15 100644
>>
>> --- a/include/lldb/Target/Process.h
>>
>> +++ b/include/lldb/Target/Process.h
>>
>> @@ -3401,6 +3401,7 @@ protected:
>>
>>  std::map m_resolved_indirect_addresses;
>>
>>  bool m_destroy_in_process;
>>
>>  bool m_can_interpret_function_calls; // Some targets, e.g the OSX
>> kernel, don't support the ability to modify the stack.
>>
>> +bool m_load_core; // True if we are looking at a core dump, not at a
>> running program
>>
>>  WarningsCollection  m_warnings_issued;  // A set of object
>> pointers which have already had warnings printed
>>
>>
>>
>>  enum {
>>
>> diff --git a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>> b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>>
>> index 5b5d98a..fa057f1 100644
>>
>> --- a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>>
>> +++ b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>>
>> @@ -559,11 +559,10 @@
>> ProcessElfCore::ParseThreadContextsFromNoteSegment(const
>> elf::ELFProgramHeader *
>>
>>  have_prstatus = true;
>>
>>  prstatus.Parse(note_data, arch);
>>
>>  thread_data->signo = prstatus.pr_cursig;
>>
>> +thread_data->tid = prstatus.pr_pid;
>>
>>  header_size = ELFLinuxPrStatus::GetSize(arch);
>>
>>  len = note_data.GetByteSize() - header_size;
>>
>>  thread_data->gpregset = DataExtractor(note_data,
>> header_size, len);
>>
>> -// FIXME: Obtain actual tid on Linux
>>
>> -thread_data->tid = m_thread_data.size();
>>
>>  break;
>>
>>  case NT_FPREGSET:
>>
>>  thread_data->fpregset = note_data;
>>
>> diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
>>
>> index e4fe419..489b307 100644
>>
>> --- a/source/Target/Process.cpp
>>
>> +++ b/source/Target/Process.cpp
>>
>> @@ -767,6 +767,7 @@ Process::Process(lldb::TargetSP target_sp, Listener
>> &listener, const UnixSignals
>>
>>  m_last_broadcast_state (eStateInvalid),
>>
>>  m_destroy_in_process (false),
>>
>>  m_can_interpret_function_calls(false),
>>
>> +m_load_core(false),
>>
>>  m_warnings_issued (),
>>
>>  m_can_jit(eCanJITDontKnow)
>>
>> {
>>
>> @@ -3088,6 +3089,7 @@ Process::LoadCore ()
>>
>>  // We successfully loaded a core file, now pretend we stopped so
>> we can
>>
>>  // show all of the threads in the core file and explore the
>> crashed
>>
>>  // state.
>>
>> +m_load_core = true;
>>
>>  SetPrivateState (eStateStop

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

[Greg Clayton via lldb-dev]

> 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
> inline int g(int n)
> {
> return n+1;
> }
> 
> // foo.cpp
> #include "foo.h"
> int main(int argc, char** argv)
> {
> return f(argc);
> }
> 
> PDB gives me back line numbers and address range grouped by file.  So I get 
> all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's lines.  In 
> sorted form, the lines for g will appear inside the sequence of lines for f.  
> So that's how the situation was arising.
> 
> Just to clarify here.  When I was encountering this problem, I would create 
> one LineSequence for foo.h's lines, one LineSequence for bar.h's lines, and 
> one for foo.cpp's.  And each one is monotonically increasing, but the ranges 
> can overlap as per the previous explanation, which was causing 
> InsertLineSequence to fail. 


I understand now. Yes, you will need to parse all line entries one big buffer, 
sort them by address, and then figure out what sequences to submit after this.

Is there a termination entry for the last line entry in a function? Lets say 
there were 4096 byte gaps between "f" and "g" and "main"? Are there termination 
entries for the last '}' in each function so that when you put all of the line 
entries into one large collection and sort them by address, that you know there 
is a gap between the line entries? This is very important to get right. If 
there aren't termination entries, you will need to add them manually by looking 
up each line entry address and find the address range of the function (which 
you can cache at the time of making the line sequences from the sorted PDB line 
entries) and add termination entries for the ends of functions. So lets say f 
starts at 0x1000 and the "inline int f" is on line 3, g starts at 0x2000 and 
main starts at 0x3000, you don't want you line table looking like a single 
sequence:

0x1000: foo.cpp line 4  // {
0x1010: foo.cpp line 5  // return g(n) + 1;
0x1020: foo.cpp line 6  // }
0x2000: foo.cpp line 10 // {
0x2010: foo.cpp line 11 // return n+1;
0x2020: foo.cpp line 12 // }
0x3000: foo.cpp line 17 // {
0x3010: foo.cpp line 18 // return f(argc);
0x3020: foo.cpp line 19 // }

If you don't have termination entries, we will think foo.cpp:6 goes from 
[0x1020-0x2000) which is probably now what we want.

There should be termination entries between the functions so that the line 
entries do not contain gaps between functions in their address ranges. So you 
should actually have 3 sequences in the line table:

0x1000: foo.cpp line 4  // {
0x1010: foo.cpp line 5  // return g(n) + 1;
0x1020: foo.cpp line 6  // }
0x1030: END

0x2000: foo.cpp line 10 // {
0x2010: foo.cpp line 11 // return n+1;
0x2020: foo.cpp line 12 // }
0x2030: END

0x3000: foo.cpp line 17 // {
0x3010: foo.cpp line 18 // return f(argc);
0x3020: foo.cpp line 19 // }
0x3030: END

0x1030, 0x2030 and 0x3030 are the end addresses of the functions f, g and main 
respectively. So if your line table only contains start addresses, you will 
need to inject these correctly otherwise source level single step can do the 
wrong thing since it uses line entry address ranges to implement the steps.

Greg

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

> 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 assumption not true for all platforms? Basically, I would like to 
> show the memory range of the whole module, instead of just text section, so 
> that if a debugger user got a magic address, he can quickly examine the image 
> list to see which binary this address falls into. I guess I can calculate and 
> combine all sections, but it is a bit cumbersome to do. 

That is not correct for all platforms. On MacOSX, any shared library in your 
DYLD shared cache will have its sections mapped all over the place:

libfoo.dylib __TEXT 0x10
barfoo.dylib __TEXT 0x20
libfoo.dylib __DATA 0x810
barfoo.dylib __TEXT 0x820
libfoo.dylib __OBJC 0x910
barfoo.dylib __OBJC 0x920

So you can't make any assumptions. That being said, each platform has the 
notion of where a library is actually loaded. For MacOSX, this is the address 
of the __TEXT segment. Not sure for other platforms.

The easy thing for you to do it to show the largest address range that contains 
all sections in a shared library. Get all sections from the module and then 
calculate the min and max address of all sections and then use the largest 
address range so show the addresses that the shared library could contain. It 
doesn't mean that a shared library does contain and address since the above 
shared libraries from my example above would be something like:


libfoo.dylib [0x10 - 0x91f]
barfoo.dylib [0x20 - 0x92f]


Note that they overlap, but this does show correct info to the user... 


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26790] New: IRForTarget

[via lldb-dev]

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
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: luke.drumm...@codeplay.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

It looks like the recent changes committed in r260768 have caused regressions
when trying to call functions that take any arguments whose typename is the
result of a `typedef` involving untagged struct types.

e.g

```c++
typedef {
float f;
int i;
} mystruct;

mystruct s;
void somefunc(mystruct *s){}


int $__lldb_expr()
{
;
somefunc(&s);
}
```

lldb versions previous to r260768 resolved the anonymous struct without a
problem, though r260768 and later fail to match the function instead failing
with the following error:

> "error: Couldn't lookup symbols:
>multiply($_0*)
.

It seems that calling functions through pointers returned by
`IRForTarget::ResolveFunctionPointers` has been removed in favor of direct
calls through the function by name. That function previously called
IRForTarget::GetFunctionAddress` to resolve a function, and seems to have had
more robust lookups for matching functions did symbol/type resolution through.

I've attached a diff for a failing testcase, that I think would be helpful to
catch this regression in future. I haven't committed this test to the lldb
source tree yet, as I understand this may unduly upset the buildbots.

Apologies for the delay here, but it was a few days after this change went in
that we got this change locally.

Let me know if there's anything I can do to help test this, as I'm keen to get
this resolved as soon as possible - therwise it seems like the best course of
action is to revert r260768 as it seems there might still be some teething
problems with this commit (https://llvm.org/bugs/show_bug.cgi?id=26694

FindCodeSymbolInContext

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Zachary Turner via lldb-dev]

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 don't know if it's appropriate to set is_terminal_entry to true here
because that's a valid line with a valid address. Terminal entries are
ignored when doing address lookups so this line would never be found when
looking up that address.

What i might be able to do is figure out the size of the epilogue and
inject a new entry with address=epilogue_addr+epilogue_size and make that
the termination entry does that work? If so what should i set for its line
number?

Just to make sure I understand, does "terminal entry" specifically mean the
end of a *function*? Reading the code I thought it meant the end of a
LineSequence
On Tue, Mar 1, 2016 at 10:33 AM Greg Clayton  wrote:

>
> > 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
> > inline int g(int n)
> > {
> > return n+1;
> > }
> >
> > // foo.cpp
> > #include "foo.h"
> > int main(int argc, char** argv)
> > {
> > return f(argc);
> > }
> >
> > PDB gives me back line numbers and address range grouped by file.  So I
> get all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's
> lines.  In sorted form, the lines for g will appear inside the sequence of
> lines for f.  So that's how the situation was arising.
> >
> > Just to clarify here.  When I was encountering this problem, I would
> create one LineSequence for foo.h's lines, one LineSequence for bar.h's
> lines, and one for foo.cpp's.  And each one is monotonically increasing,
> but the ranges can overlap as per the previous explanation, which was
> causing InsertLineSequence to fail.
>
>
> I understand now. Yes, you will need to parse all line entries one big
> buffer, sort them by address, and then figure out what sequences to submit
> after this.
>
> Is there a termination entry for the last line entry in a function? Lets
> say there were 4096 byte gaps between "f" and "g" and "main"? Are there
> termination entries for the last '}' in each function so that when you put
> all of the line entries into one large collection and sort them by address,
> that you know there is a gap between the line entries? This is very
> important to get right. If there aren't termination entries, you will need
> to add them manually by looking up each line entry address and find the
> address range of the function (which you can cache at the time of making
> the line sequences from the sorted PDB line entries) and add termination
> entries for the ends of functions. So lets say f starts at 0x1000 and the
> "inline int f" is on line 3, g starts at 0x2000 and main starts at 0x3000,
> you don't want you line table looking like a single sequence:
>
> 0x1000: foo.cpp line 4  // {
> 0x1010: foo.cpp line 5  // return g(n) + 1;
> 0x1020: foo.cpp line 6  // }
> 0x2000: foo.cpp line 10 // {
> 0x2010: foo.cpp line 11 // return n+1;
> 0x2020: foo.cpp line 12 // }
> 0x3000: foo.cpp line 17 // {
> 0x3010: foo.cpp line 18 // return f(argc);
> 0x3020: foo.cpp line 19 //  }
>
> If you don't have termination entries, we will think foo.cpp:6 goes from
> [0x1020-0x2000) which is probably now what we want.
>
> There should be termination entries between the functions so that the line
> entries do not contain gaps between functions in their address ranges. So
> you should actually have 3 sequences in the line table:
>
> 0x1000: foo.cpp line 4  // {
> 0x1010: foo.cpp line 5  // return g(n) + 1;
> 0x1020: foo.cpp line 6  // }
> 0x1030: END
>
> 0x2000: foo.cpp line 10 // {
> 0x2010: foo.cpp line 11 // return n+1;
> 0x2020: foo.cpp line 12 // }
> 0x2030: END
>
> 0x3000: foo.cpp line 17 // {
> 0x3010: foo.cpp line 18 // return f(argc);
> 0x3020: foo.cpp line 19 //  }
> 0x3030: END
>
> 0x1030, 0x2030 and 0x3030 are the end addresses of the functions f, g and
> main respectively. So if your line table only contains start addresses, you
> will need to inject these correctly otherwise source level single step can
> do the wrong thing since it uses line entry address ranges to implement the
> steps.
>
> Greg
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

> 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 
> bytes, since that only refers to the first byte of the epilogue.

I don't believe any compilers set is_eqilogue correctly yet.

> But I don't know if it's appropriate to set is_terminal_entry to true here 
> because that's a valid line with a valid address. Terminal entries are 
> ignored when doing address lookups so this line would never be found when 
> looking up that address.

The "is_terminal_entry" are to provide the address range for the last line in a 
sequence. It's line number doesn't mean anything, but it is typically the same 
as the previous one.
> 
> What i might be able to do is figure out the size of the epilogue and inject 
> a new entry with address=epilogue_addr+epilogue_size and make that the 
> termination entry does that work? If so what should i set for its line number?

The line number can just be the same as the previous one. We need to make sure 
we cover every byte of a function with a valid line entry. Anywhere the user 
can actually stop should have a valid line entry when possible.
> 
> Just to make sure I understand, does "terminal entry" specifically mean the 
> end of a *function*? Reading the code I thought it meant the end of a 
> LineSequence

No, it just is there to indicate that it terminates the previous line entry 
since line entries are stored with start address only. If a function is 
discontiguous, or if it has data in the middle, a function might have multiple 
sequences. So the terminal entry is just to provide an address range for the 
last line entry in a contiguous address range of line entries.

> On Tue, Mar 1, 2016 at 10:33 AM Greg Clayton  wrote:
> 
> > 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
> > inline int g(int n)
> > {
> > return n+1;
> > }
> >
> > // foo.cpp
> > #include "foo.h"
> > int main(int argc, char** argv)
> > {
> > return f(argc);
> > }
> >
> > PDB gives me back line numbers and address range grouped by file.  So I get 
> > all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's lines.  In 
> > sorted form, the lines for g will appear inside the sequence of lines for 
> > f.  So that's how the situation was arising.
> >
> > Just to clarify here.  When I was encountering this problem, I would create 
> > one LineSequence for foo.h's lines, one LineSequence for bar.h's lines, and 
> > one for foo.cpp's.  And each one is monotonically increasing, but the 
> > ranges can overlap as per the previous explanation, which was causing 
> > InsertLineSequence to fail.
> 
> 
> I understand now. Yes, you will need to parse all line entries one big 
> buffer, sort them by address, and then figure out what sequences to submit 
> after this.
> 
> Is there a termination entry for the last line entry in a function? Lets say 
> there were 4096 byte gaps between "f" and "g" and "main"? Are there 
> termination entries for the last '}' in each function so that when you put 
> all of the line entries into one large collection and sort them by address, 
> that you know there is a gap between the line entries? This is very important 
> to get right. If there aren't termination entries, you will need to add them 
> manually by looking up each line entry address and find the address range of 
> the function (which you can cache at the time of making the line sequences 
> from the sorted PDB line entries) and add termination entries for the ends of 
> functions. So lets say f starts at 0x1000 and the "inline int f" is on line 
> 3, g starts at 0x2000 and main starts at 0x3000, you don't want you line 
> table looking like a single sequence:
> 
> 0x1000: foo.cpp line 4  // {
> 0x1010: foo.cpp line 5  // return g(n) + 1;
> 0x1020: foo.cpp line 6  // }
> 0x2000: foo.cpp line 10 // {
> 0x2010: foo.cpp line 11 // return n+1;
> 0x2020: foo.cpp line 12 // }
> 0x3000: foo.cpp line 17 // {
> 0x3010: foo.cpp line 18 // return f(argc);
> 0x3020: foo.cpp line 19 //  }
> 
> If you don't have termination entries, we will think foo.cpp:6 goes from 
> [0x1020-0x2000) which is probably now what we want.
> 
> There should be termination entries between the functions so that the line 
> entries do not contain gaps between functions in their address ranges. So you 
> should actually have 3 sequences in the line table:
> 
> 0x1000: foo.cpp line 4  // {
> 0x1010: foo.cpp line 5  // return g(n) + 1;
> 0x1020: foo.cpp line 6  // }
> 0x1030: END
> 
> 0x2000: foo.cpp line 10 // {
> 0x2010: foo.cpp lin

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

[Zachary Turner via lldb-dev]

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 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.
>
> I don't believe any compilers set is_eqilogue correctly yet.
>
> > But I don't know if it's appropriate to set is_terminal_entry to true
> here because that's a valid line with a valid address. Terminal entries are
> ignored when doing address lookups so this line would never be found when
> looking up that address.
>
> The "is_terminal_entry" are to provide the address range for the last line
> in a sequence. It's line number doesn't mean anything, but it is typically
> the same as the previous one.
> >
> > What i might be able to do is figure out the size of the epilogue and
> inject a new entry with address=epilogue_addr+epilogue_size and make that
> the termination entry does that work? If so what should i set for its line
> number?
>
> The line number can just be the same as the previous one. We need to make
> sure we cover every byte of a function with a valid line entry. Anywhere
> the user can actually stop should have a valid line entry when possible.
> >
> > Just to make sure I understand, does "terminal entry" specifically mean
> the end of a *function*? Reading the code I thought it meant the end of a
> LineSequence
>
> No, it just is there to indicate that it terminates the previous line
> entry since line entries are stored with start address only. If a function
> is discontiguous, or if it has data in the middle, a function might have
> multiple sequences. So the terminal entry is just to provide an address
> range for the last line entry in a contiguous address range of line entries.
>
> > On Tue, Mar 1, 2016 at 10:33 AM Greg Clayton  wrote:
> >
> > > 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
> > > inline int g(int n)
> > > {
> > > return n+1;
> > > }
> > >
> > > // foo.cpp
> > > #include "foo.h"
> > > int main(int argc, char** argv)
> > > {
> > > return f(argc);
> > > }
> > >
> > > PDB gives me back line numbers and address range grouped by file.  So
> I get all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's
> lines.  In sorted form, the lines for g will appear inside the sequence of
> lines for f.  So that's how the situation was arising.
> > >
> > > Just to clarify here.  When I was encountering this problem, I would
> create one LineSequence for foo.h's lines, one LineSequence for bar.h's
> lines, and one for foo.cpp's.  And each one is monotonically increasing,
> but the ranges can overlap as per the previous explanation, which was
> causing InsertLineSequence to fail.
> >
> >
> > I understand now. Yes, you will need to parse all line entries one big
> buffer, sort them by address, and then figure out what sequences to submit
> after this.
> >
> > Is there a termination entry for the last line entry in a function? Lets
> say there were 4096 byte gaps between "f" and "g" and "main"? Are there
> termination entries for the last '}' in each function so that when you put
> all of the line entries into one large collection and sort them by address,
> that you know there is a gap between the line entries? This is very
> important to get right. If there aren't termination entries, you will need
> to add them manually by looking up each line entry address and find the
> address range of the function (which you can cache at the time of making
> the line sequences from the sorted PDB line entries) and add termination
> entries for the ends of functions. So lets say f starts at 0x1000 and the
> "inline int f" is on line 3, g starts at 0x2000 and main starts at 0x3000,
> you don't want you line table looking like a single sequence:
> >
> > 0x1000: foo.cpp line 4  // {
> > 0x1010: foo.cpp line 5  // return g(n) + 1;
> > 0x1020: foo.cpp line 6  // }
> > 0x2000: foo.cpp line 10 // {
> > 0x2010: foo.cpp line 11 // return n+1;
> > 0x2020: foo.cpp line 12 // }
> > 0x3000: foo.cpp line 17 // {
> > 0x3010: foo.cpp line 18 // return f(argc);
> > 0x3020: foo.cpp line 19 //  }
> >
> > If you don't have termination entries, we will think foo.cpp:6 goes from
> [0x1020-0x2000) which is probably now what we want.
> >
> > There should be termination entries between the functions so that the
> line entries do not contain gaps between functions in

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

[Greg Clayton via lldb-dev]

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.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] March LLVM bay-area social is this Thursday!

[George Burgess IV via lldb-dev]

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/listinfo/lldb-dev