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

[Daniel Sanders via lldb-dev]

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 
2dedc6136d7cfbac8348652c543887964d92393c)
Native: All ok
Cross compiling to MIPS: All ok

clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: 
f286149dbb2ea7e194c5c3719b6cded476f6e65f)
All ok (aside from non-regression failures in check-all).
There were two kinds of check-all failure:
* mips64 sanitizers. Not a regression since mip64 sanitizers didn't 
ship in 3.7.1
* atomic tests fail due to missing -latomic on link. Not a regression 
since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on llvm-lit).
Failing Tests (76):
AddressSanitizer-mips64-linux :: 
TestCases/Posix/coverage-direct-activation.cc
AddressSanitizer-mips64-linux :: 
TestCases/Posix/coverage-direct-large.cc
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct.cc
AddressSanitizer-mips64-linux :: 
TestCases/Posix/coverage-fork-direct.cc
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc
DataFlowSanitizer :: custom.cc
DataFlowSanitizer :: propagate.c
LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc
LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc
LeakSanitizer-Standalone :: TestCases/swapcontext.cc
LeakSanitizer-Standalone :: TestCases/use_registers.cc
MemorySanitizer :: Linux/process_vm_readv.cc
MemorySanitizer :: allocator_mapping.cc
MemorySanitizer :: dlerror.cc
MemorySanitizer :: dtls_test.c
MemorySanitizer :: memcmp_test.cc
MemorySanitizer :: msan_print_shadow3.cc
MemorySanitizer :: param_tls_limit.cc
MemorySanitizer :: unaligned_read_origin.cc
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.SmallPreAllocatedStackThread
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.UnalignedLoad
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.UnalignedStore16
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise2
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.UnalignedStore32
MemorySanitizer-Unit :: 
Msan-mips64-Test/MemorySanitizer.gethostbyname_r_erange
MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.ptrtoint
MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.shmat
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.UnalignedLoad
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise2
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore32
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange
MemorySanitizer-Unit :: 
Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint
SanitizerCommon-Unit :: 
Sanitizer-mips64-Test/SanitizerCommon.FileOps
SanitizerCommon-Unit :: 
Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC
SanitizerCommon-Unit :: 
Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE
SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc
ThreadSanitizer-mips64 :: atexit2.cc
ThreadSanitizer-mips64 :: deadlock_detector_stress_test.cc
ThreadSanitizer-mips64 :: java_alloc.cc
ThreadSanitizer-mips64 :: java_race_pc.cc
ThreadSanitizer-mips64 :: longjmp.cc
ThreadSanitizer-mips64 :: longjmp2.cc
ThreadSanitizer-mips64 :: longjmp3.cc
ThreadSanitizer-mips64 :: longjmp4.cc
ThreadSanitizer-mips64 :: map32bit.cc
ThreadSanitizer-mips64 :: race_on_mutex.c
ThreadSanitizer-mips64 :: signal_longjmp.cc
libc++ :: std/atomics/atomics.types.generic/integral.pass.cpp
libc++ :: 
std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong.pass.cpp
libc++ :: 
std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong_explicit.pass.cpp
libc++ :: 
std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak.pass.cpp
libc++ :: 
std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchan

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

[Jim Ingham via lldb-dev]

> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am trying to listen for module/symbol load/unload events and display them 
> in output UI so that debugger users can have a basic clue what is debugger 
> busy doing while launching a big executable linking many shared libraries.
> 
> Questions:
> 1. I did not find an API to get current load/unload module during module 
> events. I was expecting some static API like lldb.SBModule(or 
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
> treat current PC's module as loading module in module load/unload events. But 
> that does not work too(I think because process is not stopped in module 
> load/unload events). Do I miss something here?

From SBTarget.h:

static uint32_t
GetNumModulesFromEvent (const lldb::SBEvent &event);

static lldb::SBModule
GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent &event);

Note, you can also cause the process to stop with modules are loaded with the 
setting:

target.process.stop-on-sharedlibrary-events

if that is more convenient for you.

> 
> 2. Even though "image list" shows I have around 42 modules loaded in process, 
> I only got two module load events. Why is that?

On OS X the loader loads the closure of modules for whatever it is loading, and 
only stops and informs the debugger when this is all done.  So it is quite 
usual to see only a few load events even though many modules get loaded.


> 
> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
> Apparently I have the symbols next to the binary. 

That event gets sent when symbols are added to an already loaded module.  It is 
so a UI will know to refresh the backtrace, local variables, source view, etc 
when code goes from having no symbols to having some symbols.  Those actions 
are not needed if the library & its symbols get loaded simultaneously, so it 
isn’t sent in that case.

Jim


> 
> This is tested on mac OSX lldb.
> 
> Jeffrey
> ___
> 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] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

> On Feb 28, 2016, at 2:17 PM, Paul Peet  wrote:
> 
> Hey,
> 
> Just to let you know that I think I made some progress in determine the 
> problem.
> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
> tried the code on it. To my surprise it gave me proper output without
> non-determinism. YEY.
> I still don't have any idea why it's not working on my host system. I
> might try testing linux 4.4 like I did on the vm.
> 
> Do you have any idea/suspicion why it might not work on my system. (I
> can provide additional information if needed).

I don't. Maybe some of the linux experts out there might be able to help you. 
Are are working with top of tree LLDB sources right? You might post the exact 
linux setup you have in case that might allow people to help you out...

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

[Jeffrey Tan via lldb-dev]

This is very useful, thanks for the info!

On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:

>
> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
>
> Questions:
> 1. I did not find an API to get current load/unload module during module
> events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
>
>
> From SBTarget.h:
>
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
>
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
>
> Note, you can also cause the process to stop with modules are loaded with
> the setting:
>
> target.process.stop-on-sharedlibrary-events
>
> if that is more convenient for you.
>
>
> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
>
>
> On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
>
>
>
> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is
> no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
>
>
> That event gets sent when symbols are added to an already loaded module.
> It is so a UI will know to refresh the backtrace, local variables, source
> view, etc when code goes from having no symbols to having some symbols.
> Those actions are not needed if the library & its symbols get loaded
> simultaneously, so it isn’t sent in that case.
>
> Jim
>
>
>
> This is tested on mac OSX lldb.
>
> Jeffrey
> ___
> 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

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

[Mikhail Filimonov via lldb-dev]

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

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

[Greg Clayton via lldb-dev]

In general where you see the event bits defined like SBTarget.h for your case, 
the class that contains the event bit definitions:

class SBTarget
{
public:
//--
// Broadcaster bits.
//--
enum
{
eBroadcastBitBreakpointChanged  = (1 << 0),
eBroadcastBitModulesLoaded  = (1 << 1),
eBroadcastBitModulesUnloaded= (1 << 2),
eBroadcastBitWatchpointChanged  = (1 << 3),
eBroadcastBitSymbolsLoaded  = (1 << 4)
};
...


Also contains all of the static functions that can extract data from those 
events:


class SBTarget
{
public:
...
static bool
EventIsTargetEvent (const lldb::SBEvent &event);

static lldb::SBTarget
GetTargetFromEvent (const lldb::SBEvent &event);

static uint32_t
GetNumModulesFromEvent (const lldb::SBEvent &event);

static lldb::SBModule
GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent &event);


Greg Clayton



> On Feb 29, 2016, at 11:59 AM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> This is very useful, thanks for the info!
> 
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> 
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I am trying to listen for module/symbol load/unload events and display them 
>> in output UI so that debugger users can have a basic clue what is debugger 
>> busy doing while launching a big executable linking many shared libraries.
>> 
>> Questions:
>> 1. I did not find an API to get current load/unload module during module 
>> events. I was expecting some static API like lldb.SBModule(or 
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
>> treat current PC's module as loading module in module load/unload events. 
>> But that does not work too(I think because process is not stopped in module 
>> load/unload events). Do I miss something here?
> 
> From SBTarget.h:
> 
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
> 
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent 
> &event);
> 
> Note, you can also cause the process to stop with modules are loaded with the 
> setting:
> 
> target.process.stop-on-sharedlibrary-events
> 
> if that is more convenient for you.
> 
>> 
>> 2. Even though "image list" shows I have around 42 modules loaded in 
>> process, I only got two module load events. Why is that?
> 
> On OS X the loader loads the closure of modules for whatever it is loading, 
> and only stops and informs the debugger when this is all done.  So it is 
> quite usual to see only a few load events even though many modules get loaded.
> 
> 
>> 
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
>> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
>> Apparently I have the symbols next to the binary. 
> 
> That event gets sent when symbols are added to an already loaded module.  It 
> is so a UI will know to refresh the backtrace, local variables, source view, 
> etc when code goes from having no symbols to having some symbols.  Those 
> actions are not needed if the library & its symbols get loaded 
> simultaneously, so it isn’t sent in that case.
> 
> Jim
> 
> 
>> 
>> This is tested on mac OSX lldb.
>> 
>> Jeffrey
>> ___
>> 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

___
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

[Jeffrey Tan via lldb-dev]

I see why I did not find them in the first place. These two APIs are not
listed in the official doc:
http://lldb.llvm.org/python_reference/index.html

Someone might want to add it.

Thanks
Jeffrey

On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan 
wrote:

> This is very useful, thanks for the info!
>
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
>
>>
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I am trying to listen for module/symbol load/unload events and display
>> them in output UI so that debugger users can have a basic clue what is
>> debugger busy doing while launching a big executable linking many shared
>> libraries.
>>
>> Questions:
>> 1. I did not find an API to get current load/unload module during module
>> events. I was expecting some static API like lldb.SBModule(or
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
>> treat current PC's module as loading module in module load/unload events.
>> But that does not work too(I think because process is not stopped in module
>> load/unload events). Do I miss something here?
>>
>>
>> From SBTarget.h:
>>
>> static uint32_t
>> GetNumModulesFromEvent (const lldb::SBEvent &event);
>>
>> static lldb::SBModule
>> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
>> &event);
>>
>> Note, you can also cause the process to stop with modules are loaded with
>> the setting:
>>
>> target.process.stop-on-sharedlibrary-events
>>
>> if that is more convenient for you.
>>
>>
>> 2. Even though "image list" shows I have around 42 modules loaded in
>> process, I only got two module load events. Why is that?
>>
>>
>> On OS X the loader loads the closure of modules for whatever it is
>> loading, and only stops and informs the debugger when this is all done.  So
>> it is quite usual to see only a few load events even though many modules
>> get loaded.
>>
>>
>>
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is
>> no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
>> Apparently I have the symbols next to the binary.
>>
>>
>> That event gets sent when symbols are added to an already loaded module.
>> It is so a UI will know to refresh the backtrace, local variables, source
>> view, etc when code goes from having no symbols to having some symbols.
>> Those actions are not needed if the library & its symbols get loaded
>> simultaneously, so it isn’t sent in that case.
>>
>> Jim
>>
>>
>>
>> This is tested on mac OSX lldb.
>>
>> Jeffrey
>> ___
>> 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] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

Greg, missed your reply. Yeah, the problem is that I only looked at the
python API(which is what I am using) doc which does not contain these APIs.

On Mon, Feb 29, 2016 at 12:43 PM, Greg Clayton  wrote:

> In general where you see the event bits defined like SBTarget.h for your
> case, the class that contains the event bit definitions:
>
> class SBTarget
> {
> public:
> //--
> // Broadcaster bits.
> //--
> enum
> {
> eBroadcastBitBreakpointChanged  = (1 << 0),
> eBroadcastBitModulesLoaded  = (1 << 1),
> eBroadcastBitModulesUnloaded= (1 << 2),
> eBroadcastBitWatchpointChanged  = (1 << 3),
> eBroadcastBitSymbolsLoaded  = (1 << 4)
> };
> ...
>
>
> Also contains all of the static functions that can extract data from those
> events:
>
>
> class SBTarget
> {
> public:
> ...
> static bool
> EventIsTargetEvent (const lldb::SBEvent &event);
>
> static lldb::SBTarget
> GetTargetFromEvent (const lldb::SBEvent &event);
>
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
>
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
>
>
> Greg Clayton
>
>
>
> > On Feb 29, 2016, at 11:59 AM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This is very useful, thanks for the info!
> >
> > On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> >
> >> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
> >>
> >> Questions:
> >> 1. I did not find an API to get current load/unload module during
> module events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
> >
> > From SBTarget.h:
> >
> > static uint32_t
> > GetNumModulesFromEvent (const lldb::SBEvent &event);
> >
> > static lldb::SBModule
> > GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
> >
> > Note, you can also cause the process to stop with modules are loaded
> with the setting:
> >
> > target.process.stop-on-sharedlibrary-events
> >
> > if that is more convenient for you.
> >
> >>
> >> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
> >
> > On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
> >
> >
> >>
> >> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
> >
> > That event gets sent when symbols are added to an already loaded
> module.  It is so a UI will know to refresh the backtrace, local variables,
> source view, etc when code goes from having no symbols to having some
> symbols.  Those actions are not needed if the library & its symbols get
> loaded simultaneously, so it isn’t sent in that case.
> >
> > Jim
> >
> >
> >>
> >> This is tested on mac OSX lldb.
> >>
> >> Jeffrey
> >> ___
> >> 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
>
>
___
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

[Jeffrey Tan via lldb-dev]

Btw: I did not find an API to retrieve the load address of the SBModule?
This seems to be weird to me, did I miss anything?


On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan 
wrote:

> I see why I did not find them in the first place. These two APIs are not
> listed in the official doc:
> http://lldb.llvm.org/python_reference/index.html
>
> Someone might want to add it.
>
> Thanks
> Jeffrey
>
> On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan 
> wrote:
>
>> This is very useful, thanks for the info!
>>
>> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
>>
>>>
>>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to listen for module/symbol load/unload events and display
>>> them in output UI so that debugger users can have a basic clue what is
>>> debugger busy doing while launching a big executable linking many shared
>>> libraries.
>>>
>>> Questions:
>>> 1. I did not find an API to get current load/unload module during module
>>> events. I was expecting some static API like lldb.SBModule(or
>>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
>>> treat current PC's module as loading module in module load/unload events.
>>> But that does not work too(I think because process is not stopped in module
>>> load/unload events). Do I miss something here?
>>>
>>>
>>> From SBTarget.h:
>>>
>>> static uint32_t
>>> GetNumModulesFromEvent (const lldb::SBEvent &event);
>>>
>>> static lldb::SBModule
>>> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
>>> &event);
>>>
>>> Note, you can also cause the process to stop with modules are loaded
>>> with the setting:
>>>
>>> target.process.stop-on-sharedlibrary-events
>>>
>>> if that is more convenient for you.
>>>
>>>
>>> 2. Even though "image list" shows I have around 42 modules loaded in
>>> process, I only got two module load events. Why is that?
>>>
>>>
>>> On OS X the loader loads the closure of modules for whatever it is
>>> loading, and only stops and informs the debugger when this is all done.  So
>>> it is quite usual to see only a few load events even though many modules
>>> get loaded.
>>>
>>>
>>>
>>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
>>> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
>>> Apparently I have the symbols next to the binary.
>>>
>>>
>>> That event gets sent when symbols are added to an already loaded
>>> module.  It is so a UI will know to refresh the backtrace, local variables,
>>> source view, etc when code goes from having no symbols to having some
>>> symbols.  Those actions are not needed if the library & its symbols get
>>> loaded simultaneously, so it isn’t sent in that case.
>>>
>>> Jim
>>>
>>>
>>>
>>> This is tested on mac OSX lldb.
>>>
>>> Jeffrey
>>> ___
>>> 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] Questions for module/symbol load/unload events

[Jim Ingham via lldb-dev]

There isn’t necessarily A load address for an SBModule.  After all, the 
different segments could load with different offsets.  We usually list the 
offset of the __TEXT__ address as the load address - for instance in “image 
list", since if you are only interested in symbolication, that’s what you care 
about.  But there isn’t just one load address.

Jim

> On Feb 29, 2016, at 2:02 PM, Jeffrey Tan  wrote:
> 
> Btw: I did not find an API to retrieve the load address of the SBModule? This 
> seems to be weird to me, did I miss anything?
> 
> 
> On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan  > wrote:
> I see why I did not find them in the first place. These two APIs are not 
> listed in the official doc:
> http://lldb.llvm.org/python_reference/index.html 
> 
> 
> Someone might want to add it.
> 
> Thanks
> Jeffrey
> 
> On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan  > wrote:
> This is very useful, thanks for the info!
> 
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  > wrote:
> 
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi,
>> 
>> I am trying to listen for module/symbol load/unload events and display them 
>> in output UI so that debugger users can have a basic clue what is debugger 
>> busy doing while launching a big executable linking many shared libraries.
>> 
>> Questions:
>> 1. I did not find an API to get current load/unload module during module 
>> events. I was expecting some static API like lldb.SBModule(or 
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
>> treat current PC's module as loading module in module load/unload events. 
>> But that does not work too(I think because process is not stopped in module 
>> load/unload events). Do I miss something here?
> 
> From SBTarget.h:
> 
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
> 
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent 
> &event);
> 
> Note, you can also cause the process to stop with modules are loaded with the 
> setting:
> 
> target.process.stop-on-sharedlibrary-events
> 
> if that is more convenient for you.
> 
>> 
>> 2. Even though "image list" shows I have around 42 modules loaded in 
>> process, I only got two module load events. Why is that?
> 
> On OS X the loader loads the closure of modules for whatever it is loading, 
> and only stops and informs the debugger when this is all done.  So it is 
> quite usual to see only a few load events even though many modules get loaded.
> 
> 
>> 
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
>> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
>> Apparently I have the symbols next to the binary. 
> 
> That event gets sent when symbols are added to an already loaded module.  It 
> is so a UI will know to refresh the backtrace, local variables, source view, 
> etc when code goes from having no symbols to having some symbols.  Those 
> actions are not needed if the library & its symbols get loaded 
> simultaneously, so it isn’t sent in that case.
> 
> Jim
> 
> 
>> 
>> This is tested on mac OSX lldb.
>> 
>> Jeffrey
>> ___
>> 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] Questions for module/symbol load/unload events

[Greg Clayton via lldb-dev]

As Jim said there really isn't just one address per module. You will want to 
display the address of each of the sections for a module under that module. So 
something like:


a.out
  |- .text @ 0x1
  |- .data @ 0x2
  \- .bss  @ 0x3


> On Feb 29, 2016, at 2:02 PM, Jeffrey Tan  wrote:
> 
> Btw: I did not find an API to retrieve the load address of the SBModule? This 
> seems to be weird to me, did I miss anything?
> 
> 
> On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan  wrote:
> I see why I did not find them in the first place. These two APIs are not 
> listed in the official doc:
> http://lldb.llvm.org/python_reference/index.html
> 
> Someone might want to add it.
> 
> Thanks
> Jeffrey
> 
> On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan  wrote:
> This is very useful, thanks for the info!
> 
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> 
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I am trying to listen for module/symbol load/unload events and display them 
>> in output UI so that debugger users can have a basic clue what is debugger 
>> busy doing while launching a big executable linking many shared libraries.
>> 
>> Questions:
>> 1. I did not find an API to get current load/unload module during module 
>> events. I was expecting some static API like lldb.SBModule(or 
>> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
>> treat current PC's module as loading module in module load/unload events. 
>> But that does not work too(I think because process is not stopped in module 
>> load/unload events). Do I miss something here?
> 
> From SBTarget.h:
> 
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
> 
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent 
> &event);
> 
> Note, you can also cause the process to stop with modules are loaded with the 
> setting:
> 
> target.process.stop-on-sharedlibrary-events
> 
> if that is more convenient for you.
> 
>> 
>> 2. Even though "image list" shows I have around 42 modules loaded in 
>> process, I only got two module load events. Why is that?
> 
> On OS X the loader loads the closure of modules for whatever it is loading, 
> and only stops and informs the debugger when this is all done.  So it is 
> quite usual to see only a few load events even though many modules get loaded.
> 
> 
>> 
>> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
>> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
>> Apparently I have the symbols next to the binary. 
> 
> That event gets sent when symbols are added to an already loaded module.  It 
> is so a UI will know to refresh the backtrace, local variables, source view, 
> etc when code goes from having no symbols to having some symbols.  Those 
> actions are not needed if the library & its symbols get loaded 
> simultaneously, so it isn’t sent in that case.
> 
> Jim
> 
> 
>> 
>> This is tested on mac OSX lldb.
>> 
>> Jeffrey
>> ___
>> 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] Making a new symbol provider

[Zachary Turner via lldb-dev]

Suppose you've got two line sequences.

First sequence:
4198512
4198544
4198547
4198562

Second sequence:
4198528
4198531
4198537
4198552

These two line sequences overlap, and will not be inserted correctly into a
LineTable.  This sounds like a bug to me, because as far as I can tell
there is nothing preventing LineSequences being organized this way,
but LineTable::InsertSequence assumes that this cannot happen.

On Fri, Feb 12, 2016 at 11:01 AM Zachary Turner  wrote:

> On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton  wrote:
>
>>
>> > 5. ParseCompileUnitLineTable.  On the LineTable class you can add "line
>> sequences" or individual entries.  What's the difference here?  Is there
>> any disadvantage to adding every single line entry in the line table using
>> the InsertLineEntry instead of building a line sequence and inserting the
>> sequence?
>>
>> The rule follows DWARF line tables: line sequences must be an array of
>> line entries whose addresses are always increasing. You can add every line
>> in sequence as long as the line entries are in increasing address order. We
>> are going to sort the line entries into an array that is sorted for quick
>> lookups.
>>
> Just to make sure I understand, semantically here, there is nothing
> special about a line sequence, it's just an optimization to let LineTable
> know you're giving it sorted values?  So any lines you add via a
> LineSequence, could also be added individually with insertLine, but it
> would be slower?  And aside from that everything else would still work as
> expected?
>
___
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 Feb 29, 2016, at 5:09 PM, Zachary Turner  wrote:
> 
> Suppose you've got two line sequences.  
> 
> First sequence:
> 4198512
> 4198544
> 4198547
> 4198562
> 
> Second sequence:
> 4198528
> 4198531
> 4198537
> 4198552
> 
> These two line sequences overlap, and will not be inserted correctly into a 
> LineTable.  This sounds like a bug to me, because as far as I can tell there 
> is nothing preventing LineSequences being organized this way, but 
> LineTable::InsertSequence assumes that this cannot happen.

Are these addresses or line numbers? If PDB can has its line tables randomly 
ordered, you will need to read all line entries out of the PDB file first into 
one big collection of all line entries, and remember if any are line 
termination entries and then make sequences out of the large collection you end 
up with.

We only expect to get one line entry for a given load address and I believe 
that is reasonable. The registration process for line entries is very DWARF 
centric right now, but I think that the end goal if having line table sequences 
in ascending order that have a single file and line for a given load address is 
a valid assumption.

So it sounds like you just need to read all of your stuff into one large buffer 
and then figure out how you want to register those sequences so they make sense.

In DWARF if you have a line tables like:

0x1000: foo.c line 1
0x1010: foo.c line 2
0x1030: foo.c line 3
0x1040: termination entry

0x2000: foo.c line 11
0x2010: foo.c line 12
0x2020: foo.c line 13
0x2050: termination entry

These are both sequences that define address ranges and we always know the 
address range of each line entry because the last entry in a contiguous line 
sequence always has a last entry to define the size of the last valid (non 
termination entry) line entry. 

How does the PDB file format emit it line table entries? Would it be equivalent 
to the DWARF with no termination entries? Something like:

0x1000: foo.c line 1
0x1010: foo.c line 2
0x1030: foo.c line 3

0x2000: foo.c line 11
0x2010: foo.c line 12
0x2020: foo.c line 13

If that is the case, how do you deal with large gaps like the gap between 
0x1040 and 0x2000?

And if I read what you are saying correctly you are saying your line tables 
might come out like:

0x1000: foo.c line 1
0x2000: foo.c line 11
0x1010: foo.c line 2
0x2010: foo.c line 12
0x1030: foo.c line 3
0x2020: foo.c line 13

Questions:

- Does PDB emit ranges for each line or just a single address?
- Does PDB have termination entries for the equivalent of address 0x1040 and 
0x2050?

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

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.

I'll upload a patch tomorrow morning, and along with it a test (which is
how I found this to begin with).  If you look at the test you will see the
exact source code and the line / address sequences that are generated.

I think I have everything working, and I wrote some test cases to validate
my assumptions.  Which is good because every test was broken at first, so I
wouldn't have been able to fix things without them.  They shoudl also help
verify that my assumptions are correct to begin with, which hopefully makes
reviewing easier.

On Mon, Feb 29, 2016 at 5:29 PM Greg Clayton  wrote:

>
> > On Feb 29, 2016, at 5:09 PM, Zachary Turner  wrote:
> >
> > Suppose you've got two line sequences.
> >
> > First sequence:
> > 4198512
> > 4198544
> > 4198547
> > 4198562
> >
> > Second sequence:
> > 4198528
> > 4198531
> > 4198537
> > 4198552
> >
> > These two line sequences overlap, and will not be inserted correctly
> into a LineTable.  This sounds like a bug to me, because as far as I can
> tell there is nothing preventing LineSequences being organized this way,
> but LineTable::InsertSequence assumes that this cannot happen.
>
> Are these addresses or line numbers? If PDB can has its line tables
> randomly ordered, you will need to read all line entries out of the PDB
> file first into one big collection of all line entries, and remember if any
> are line termination entries and then make sequences out of the large
> collection you end up with.
>
> We only expect to get one line entry for a given load address and I
> believe that is reasonable. The registration process for line entries is
> very DWARF centric right now, but I think that the end goal if having line
> table sequences in ascending order that have a single file and line for a
> given load address is a valid assumption.
>
> So it sounds like you just need to read all of your stuff into one large
> buffer and then figure out how you want to register those sequences so they
> make sense.
>
> In DWARF if you have a line tables like:
>
> 0x1000: foo.c line 1
> 0x1010: foo.c line 2
> 0x1030: foo.c line 3
> 0x1040: termination entry
>
> 0x2000: foo.c line 11
> 0x2010: foo.c line 12
> 0x2020: foo.c line 13
> 0x2050: termination entry
>
> These are both sequences that define address ranges and we always know the
> address range of each line entry because the last entry in a contiguous
> line sequence always has a last entry to define the size of the last valid
> (non termination entry) line entry.
>
> How does the PDB file format emit it line table entries? Would it be
> equivalent to the DWARF with no termination entries? Something like:
>
> 0x1000: foo.c line 1
> 0x1010: foo.c line 2
> 0x1030: foo.c line 3
>
> 0x2000: foo.c line 11
> 0x2010: foo.c line 12
> 0x2020: foo.c line 13
>
> If that is the case, how do you deal with large gaps like the gap between
> 0x1040 and 0x2000?
>
> And if I read what you are saying correctly you are saying your line
> tables might come out like:
>
> 0x1000: foo.c line 1
> 0x2000: foo.c line 11
> 0x1010: foo.c line 2
> 0x2010: foo.c line 12
> 0x1030: foo.c line 3
> 0x2020: foo.c line 13
>
> Questions:
>
> - Does PDB emit ranges for each line or just a single address?
> - Does PDB have termination entries for the equivalent of address 0x1040
> and 0x2050?
>
>
___
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]

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.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders
 wrote:
> clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 
> 2dedc6136d7cfbac8348652c543887964d92393c)
> Native: All ok
> Cross compiling to MIPS: All ok
>
> clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: 
> f286149dbb2ea7e194c5c3719b6cded476f6e65f)
> All ok (aside from non-regression failures in check-all).
> There were two kinds of check-all failure:
> * mips64 sanitizers. Not a regression since mip64 sanitizers didn't 
> ship in 3.7.1
> * atomic tests fail due to missing -latomic on link. Not a regression 
> since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on 
> llvm-lit).
> Failing Tests (76):
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-direct-activation.cc
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-direct-large.cc
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-direct.cc
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-fork-direct.cc
> AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc
> DataFlowSanitizer :: custom.cc
> DataFlowSanitizer :: propagate.c
> LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc
> LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc
> LeakSanitizer-Standalone :: TestCases/swapcontext.cc
> LeakSanitizer-Standalone :: TestCases/use_registers.cc
> MemorySanitizer :: Linux/process_vm_readv.cc
> MemorySanitizer :: allocator_mapping.cc
> MemorySanitizer :: dlerror.cc
> MemorySanitizer :: dtls_test.c
> MemorySanitizer :: memcmp_test.cc
> MemorySanitizer :: msan_print_shadow3.cc
> MemorySanitizer :: param_tls_limit.cc
> MemorySanitizer :: unaligned_read_origin.cc
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.SmallPreAllocatedStackThread
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedLoad
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore16
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise2
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore32
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.gethostbyname_r_erange
> MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.ptrtoint
> MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.shmat
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedLoad
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise2
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore32
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint
> SanitizerCommon-Unit :: 
> Sanitizer-mips64-Test/SanitizerCommon.FileOps
> SanitizerCommon-Unit :: 
> Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC
> SanitizerCommon-Unit :: 
> Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE
> SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
> SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc
> ThreadSanitizer-mips64 :: atexit2.cc
> ThreadSanitizer-mips64 :: deadlock_detector_stress_test.cc
> ThreadSanitizer-mips64 :: java_alloc.cc
> ThreadSanitizer-mips64 :: java_race_pc.cc
> ThreadSanitizer-mips64 :: longjmp.cc
> ThreadSanitizer-mips64 :: longjmp2.cc
> ThreadSanitizer-mips64 :: longjmp3.cc
> ThreadSanitizer-mips64 :: longjmp4.cc
> ThreadSanitizer-mips64 :: map32bit.cc
> ThreadSanitizer-mips64 :: race_on_mutex.c
> ThreadSanitizer-mips64 :: signal_longjmp.cc
> libc++ :: std/atomics/atomics.types.generic/integral.pass.cpp
> libc++ :: 
> std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong.pass.cpp
> libc++ :: 
> std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong_explicit.p

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

[Jeffrey Tan via lldb-dev]

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.

On Mon, Feb 29, 2016 at 4:02 PM, Greg Clayton  wrote:

> As Jim said there really isn't just one address per module. You will want
> to display the address of each of the sections for a module under that
> module. So something like:
>
>
> a.out
>   |- .text @ 0x1
>   |- .data @ 0x2
>   \- .bss  @ 0x3
>
>
> > On Feb 29, 2016, at 2:02 PM, Jeffrey Tan 
> wrote:
> >
> > Btw: I did not find an API to retrieve the load address of the SBModule?
> This seems to be weird to me, did I miss anything?
> >
> >
> > On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan 
> wrote:
> > I see why I did not find them in the first place. These two APIs are not
> listed in the official doc:
> > http://lldb.llvm.org/python_reference/index.html
> >
> > Someone might want to add it.
> >
> > Thanks
> > Jeffrey
> >
> > On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan 
> wrote:
> > This is very useful, thanks for the info!
> >
> > On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham  wrote:
> >
> >> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
> >>
> >> Questions:
> >> 1. I did not find an API to get current load/unload module during
> module events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
> >
> > From SBTarget.h:
> >
> > static uint32_t
> > GetNumModulesFromEvent (const lldb::SBEvent &event);
> >
> > static lldb::SBModule
> > GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
> >
> > Note, you can also cause the process to stop with modules are loaded
> with the setting:
> >
> > target.process.stop-on-sharedlibrary-events
> >
> > if that is more convenient for you.
> >
> >>
> >> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
> >
> > On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
> >
> >
> >>
> >> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
> >
> > That event gets sent when symbols are added to an already loaded
> module.  It is so a UI will know to refresh the backtrace, local variables,
> source view, etc when code goes from having no symbols to having some
> symbols.  Those actions are not needed if the library & its symbols get
> loaded simultaneously, so it isn’t sent in that case.
> >
> > Jim
> >
> >
> >>
> >> This is tested on mac OSX lldb.
> >>
> >> Jeffrey
> >> ___
> >> 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