[lldb-dev] Odd behavior with test TestThreadSelectionBug.py

2019-05-14 Thread Ted Woodward via lldb-dev
This test uses the responder and a python OS plugin.

When I run the full test suite, it passes, with this thread list:
runCmd: thread list
output: Process 1 stopped
* thread #1: tid = 0x0001, 0x, name = 'one', queue = 'queue1'
  thread #2: tid = 0x0002, 0x, name = 'two', queue = 'queue2'
  thread #3: tid = 0x0003, 0x, name = 'three', queue = 'queue3', stop 
reason = signal SIGINT

When I run the test by itself, it fails with this thread list:
runCmd: thread list
output: Process 1 stopped
* thread #2: tid = 0x1, 0x, name = 'one', queue = 'queue1'
  thread #3: tid = 0x2, 0x, name = 'two', queue = 'queue2'
  thread #4: tid = 0x3, 0x, name = 'three', queue = 'queue3', 
stop reason = signal SIGINT

Anyone have any idea why this is?

packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestThreadSelectionBug.py
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] LLDB Website

2019-04-24 Thread Ted Woodward via lldb-dev
That's the issue - lldb-python-doc depends on liblldb. From docs/CMakeLists.txt:

if(EPYDOC_EXECUTABLE)
  find_program(DOT_EXECUTABLE dot)
if(DOT_EXECUTABLE)
  set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath 
${DOT_EXECUTABLE})
endif()
set(DOC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/doc")
file(MAKE_DIRECTORY "${DOC_DIR}")
#set(ENV{PYTHONPATH} 
${CMAKE_CURRENT_BINARY_DIR}/../../../lib/python2.7/site-packages)
add_custom_target(lldb-python-doc
  ${EPYDOC_EXECUTABLE}
  --html
  lldb
  -o ${CMAKE_CURRENT_BINARY_DIR}/python_reference
  --name "LLDB python API"
  --url "http://lldb.llvm.org;
  ${EPYDOC_OPTIONS}
  DEPENDS swig_wrapper liblldb
  WORKING_DIRECTORY 
${CMAKE_CURRENT_BINARY_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages
  COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM
)
endif(EPYDOC_EXECUTABLE)


> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Wednesday, April 24, 2019 1:16 AM
> To: Jonas Devlieghere ; Tanya Lattner
> 
> Cc: LLDB 
> Subject: [EXT] Re: [lldb-dev] LLDB Website
> 
> On 24/04/2019 03:19, Jonas Devlieghere via lldb-dev wrote:
> >
> >
> > On Tue, Apr 23, 2019 at 6:04 PM Jonas Devlieghere
> > mailto:jo...@devlieghere.com>> wrote:
> >
> >
> >
> > On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner  > > wrote:
> >
> >
> >
> >> On Apr 23, 2019, at 5:06 PM, Jonas Devlieghere
> >> mailto:jo...@devlieghere.com>> wrote:
> >>
> >>
> >>
> >> On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner
> >> mailto:tanyalatt...@llvm.org>> wrote:
> >>
> >>
> >>
> >>> On Apr 23, 2019, at 11:54 AM, Jonas Devlieghere
> >>> mailto:jo...@devlieghere.com>>
> wrote:
> >>>
> >>> Hey Tanya,
> >>>
> >>> On Tue, Apr 23, 2019 at 11:51 Tanya Lattner
> >>> mailto:tanyalatt...@llvm.org>> wrote:
> >>>
> >>> Jonas,
> >>>
> >>> Ignore what I said before as these do need to be
> >>> separate targets. It appears the new targets are
> >>> running doxygen. This isn’t something we typically do
> >>> as a post commit hook since it takes awhile. I’ll
> >>> need to do this via the doxygen nightly script. Any
> >>> concerns?
> >>>
> >>> That sounds perfect. Can we still do the regular website
> >>> post commit?
> >>
> >> Yes, so it will do docs-lldb-html on every commit.
> >>
> >>
> >> Perfect!
> >>
> >>
> >> So I am able to generate the cpp reference docs:
> >> https://lldb.llvm.org/cpp_reference/index.html
> >>
> >> However, the main website links to
> >> https://lldb.llvm.org/cpp_reference/html/index.html. Do
> >> you want the html in that url? I can change the alias. We
> >> strip for other doxygen.
> >>
> >>
> >> Let's keep it without the html. I'll update a link on the
> >> website and add a redirect.
> >>
> >>
> >> As for python docs, what is required to build those? It's
> >> not showing up as a target for me.
> >>
> >>
> >> This is probably because you don't have `epydoc` installed
> >> (sudo pip install epydoc).
> >> I think you'll have to re-run cmake after for it to pick it
> >> up. The corresponding target should then be `lldb-python-doc`.
> >>
> >> https://lldb.llvm.org/cpp_reference/index.html
> >
> > Well installing epydoc did the trick, but I don’t think the
> > doxygen script is the right place for this target. I have not
> > dug into it yet but it appears to require some LLVM libraries
> > and is building those. I’m letting it finish to verify it builds
> > but I’ll have to sort out the best way of doing this on the
> > server. We have other scripts that generate other documentation
> > that build parts of LLVM. Ideally, I would want to leverage that
> > and reduce build times.
> >
> >
> > Yeah, the annoying thing about the Python documentation is that it
> > builds the C++ API, then runs swig to generate the Python wrapper,
> > and finally generates the docs from that.
> 
> It should be possible to solve this by tweaking the dependency graph a bit.
> There's no fundamental reason why you need to build anything in order to
> run swig. It is purely a textual step -- it ingests header files and interface
> definitions and spits out python and cpp files. The inputs are present as 
> static
> checked in source, so the swig step could theoretically be the very first 
> build
> command that we run.
> 
> > I wonder if we can just use the static bindings that are checked-in
> > instead. I will look into that later today/tomorrow.
> >
> >
> > Right, so the reason is 

Re: [lldb-dev] Where did the python/c++ API documentation go?

2019-04-22 Thread Ted Woodward via lldb-dev
Great, thanks Jim. Glad to see people are already on this.

But where do I go if I need to look at the python API right now?
(besides web.archive.org, which is what I ended up doing)

> -Original Message-
> From: jing...@apple.com 
> Sent: Monday, April 22, 2019 1:35 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: [EXT] Re: [lldb-dev] Where did the python/c++ API documentation
> go?
> 
> 
> 
> > On Apr 22, 2019, at 10:59 AM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > The new LLDB website at http://lldb.llvm.org has an external resources
> page:
> > http://lldb.llvm.org/resources/external.html
> >
> > It has 2 entries on it for Documentation:
> > https://lldb.llvm.org/python_reference/index.html
> > https://lldb.llvm.org/cpp_reference/html/index.html
> >
> > Both of these lead to “404 Not Found”:
> > The requested URL /python_reference/index.html was not found on this
> server.
> > The requested URL /cpp_reference/html/index.html was not found on this
> server.
> >
> > Where do I go to find the python/c++ API documentation now?
> >
> > BTW, I don’t think LLDB’s API documentation is an “External Resource”.
> Those links should be on the main page, along with a link to the llvm main
> page.
> 
> Both of these are known issues.  Jonas is going to move the API docs to the 
> top
> level.  IIUC this also needs some website admin intervention, which Jonas is
> waiting on.
> 
> Jim
> 
> 
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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


[lldb-dev] Where did the python/c++ API documentation go?

2019-04-22 Thread Ted Woodward via lldb-dev
The new LLDB website at http://lldb.llvm.org has an external resources page:
http://lldb.llvm.org/resources/external.html

It has 2 entries on it for Documentation:
https://lldb.llvm.org/python_reference/index.html
https://lldb.llvm.org/cpp_reference/html/index.html

Both of these lead to "404 Not Found":
The requested URL /python_reference/index.html was not found on this server.
The requested URL /cpp_reference/html/index.html was not found on this server.

Where do I go to find the python/c++ API documentation now?

BTW, I don't think LLDB's API documentation is an "External Resource". Those 
links should be on the main page, along with a link to the llvm main page.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] ThreadSanitizer reports lock-order-inversion running lldb on Ubuntu 14.04

2019-03-25 Thread Ted Woodward via lldb-dev
Some more info from my team:
Debugger:Clear() is calling StopEventHandlerThread followed by a 
m_listener_sp->Clear() and from what I can tell the EventHandlerThread isn't 
fully stopped prior to the Clear being called.

From: lldb-dev  On Behalf Of Ted Woodward via 
lldb-dev
Sent: Friday, March 22, 2019 3:28 PM
To: LLDB 
Subject: [EXT] [lldb-dev] ThreadSanitizer reports lock-order-inversion running 
lldb on Ubuntu 14.04

We've been seeing intermittent test failures in some lit tests with this error 
message:

terminating with uncaught exception of type std::__1::system_error: mutex lock 
failed: Invalid argument


We've only seen it on a buildbot running on SLES 11 - we can't reproduce it on 
our Ubuntu machines.


We build lldb with tsan turned on, and see a lock-order-inversion error with 
just a run/quit. Could this be the cause of our crash?


Build was done with ToT on Ubuntu 14.04, using clang 7.0.1 with this cmake line:
CC=clang CXX=clang++ cmake -G Ninja -DLLVM_USE_SANITIZER=Thread 
-DLLVM_ENABLE_LIBCXX=On ../llvm/

Output from the run:

> TSAN_OPTIONS=second_deadlock_stack=1 bin/lldb
(lldb) quit
==
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=11107)
  Cycle in lock order graph: M1739 (0x7b1c00b0) => M1745 (0x7b3c0040) 
=> M1739

  Mutex M1745 acquired here while holding mutex M1739 in thread T1:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Debugger::DefaultEventHandler() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1537:16 
(liblldb.so.9svn+0xd5f783)
#3 lldb_private::Debugger::EventHandlerThread(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1609:22 
(liblldb.so.9svn+0xd5fba9)
#4 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:69:10
 (liblldb.so.9svn+0xe438f2)

  Mutex M1739 previously acquired by the same thread here:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Debugger::DefaultEventHandler() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1537:16 
(liblldb.so.9svn+0xd5f783)
#3 lldb_private::Debugger::EventHandlerThread(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1609:22 
(liblldb.so.9svn+0xd5fba9)
#4 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:69:10
 (liblldb.so.9svn+0xe438f2)

  Mutex M1739 acquired here while holding mutex M1745 in main thread:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Listener::Clear() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Utility/Listener.cpp:78:19 
(liblldb.so.9svn+0x1005e58)
#3 lldb_private::Debugger::Clear()::$_0::operator()() const 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:841:20 
(liblldb.so.9svn+0xd60237)
#4 decltype(std::__1::forward(fp)()) 
std::__1::__invoke(lldb_private::Debugger::Clear()::$_0&&)
 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/type_traits:4345:1
 (liblldb.so.9svn+0xd601cc)
#5 void 
std::__1::__call_once_param
 >::__execute<>(std::__1::__tuple_indices<>) 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:621
 (liblldb.so.9svn+0xd601cc)
#6 
std::__1::__call_once_param
 >::operator()() 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:613
 (liblldb.so.9svn+0xd601cc)
#7 void 
std::__1::__call_once_proxy
 >(void*) 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:649
 (liblldb.so.9svn+0xd601cc)
#8 std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) 
 (libc++.so.1+0x53317)
#9 lldb_private::Debugger::Clear() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:837:3 
(liblldb.so.9svn+0xd5b358)
#10 
lldb_private::Debugger::Destroy(std::__1::shared_ptr&) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:699:16 
(liblldb.so.9svn+0xd5b9e6)
#11 lldb::SBDebugger::Destroy(lldb::SBDebugger&) 
/local/mnt/ted/tip/llvm/tools/lldb/source/API/SBDebugger.cpp:276:3 
(liblldb.so.9svn+0x9ddef5

[lldb-dev] ThreadSanitizer reports lock-order-inversion running lldb on Ubuntu 14.04

2019-03-22 Thread Ted Woodward via lldb-dev
We've been seeing intermittent test failures in some lit tests with this error 
message:

terminating with uncaught exception of type std::__1::system_error: mutex lock 
failed: Invalid argument


We've only seen it on a buildbot running on SLES 11 - we can't reproduce it on 
our Ubuntu machines.


We build lldb with tsan turned on, and see a lock-order-inversion error with 
just a run/quit. Could this be the cause of our crash?


Build was done with ToT on Ubuntu 14.04, using clang 7.0.1 with this cmake line:
CC=clang CXX=clang++ cmake -G Ninja -DLLVM_USE_SANITIZER=Thread 
-DLLVM_ENABLE_LIBCXX=On ../llvm/

Output from the run:

> TSAN_OPTIONS=second_deadlock_stack=1 bin/lldb
(lldb) quit
==
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=11107)
  Cycle in lock order graph: M1739 (0x7b1c00b0) => M1745 (0x7b3c0040) 
=> M1739

  Mutex M1745 acquired here while holding mutex M1739 in thread T1:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Debugger::DefaultEventHandler() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1537:16 
(liblldb.so.9svn+0xd5f783)
#3 lldb_private::Debugger::EventHandlerThread(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1609:22 
(liblldb.so.9svn+0xd5fba9)
#4 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:69:10
 (liblldb.so.9svn+0xe438f2)

  Mutex M1739 previously acquired by the same thread here:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Debugger::DefaultEventHandler() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1537:16 
(liblldb.so.9svn+0xd5f783)
#3 lldb_private::Debugger::EventHandlerThread(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1609:22 
(liblldb.so.9svn+0xd5fba9)
#4 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:69:10
 (liblldb.so.9svn+0xe438f2)

  Mutex M1739 acquired here while holding mutex M1745 in main thread:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Listener::Clear() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Utility/Listener.cpp:78:19 
(liblldb.so.9svn+0x1005e58)
#3 lldb_private::Debugger::Clear()::$_0::operator()() const 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:841:20 
(liblldb.so.9svn+0xd60237)
#4 decltype(std::__1::forward(fp)()) 
std::__1::__invoke(lldb_private::Debugger::Clear()::$_0&&)
 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/type_traits:4345:1
 (liblldb.so.9svn+0xd601cc)
#5 void 
std::__1::__call_once_param
 >::__execute<>(std::__1::__tuple_indices<>) 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:621
 (liblldb.so.9svn+0xd601cc)
#6 
std::__1::__call_once_param
 >::operator()() 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:613
 (liblldb.so.9svn+0xd601cc)
#7 void 
std::__1::__call_once_proxy
 >(void*) 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:649
 (liblldb.so.9svn+0xd601cc)
#8 std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) 
 (libc++.so.1+0x53317)
#9 lldb_private::Debugger::Clear() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:837:3 
(liblldb.so.9svn+0xd5b358)
#10 
lldb_private::Debugger::Destroy(std::__1::shared_ptr&) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:699:16 
(liblldb.so.9svn+0xd5b9e6)
#11 lldb::SBDebugger::Destroy(lldb::SBDebugger&) 
/local/mnt/ted/tip/llvm/tools/lldb/source/API/SBDebugger.cpp:276:3 
(liblldb.so.9svn+0x9ddef5)
#12 Driver::MainLoop() 
/local/mnt/ted/tip/llvm/tools/lldb/tools/driver/Driver.cpp:764:3 (lldb+0x4b518f)
#13 main /local/mnt/ted/tip/llvm/tools/lldb/tools/driver/Driver.cpp:957:26 
(lldb+0x4b5aa6)

  Mutex M1745 previously acquired by the same thread here:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 

Re: [lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded

2019-03-06 Thread Ted Woodward via lldb-dev
Hi Nat!,

The best way to do this is to go to http://reviews.llvm.org .
Under Differential, click Create Diff, then paste in the raw diff for your 
patch.
We like to see a full context diff, so reviewers can easily see the full file.

More info on how to submit a patch here: http://llvm.org/docs/Contributing.html

Ted

> -Original Message-
> From: lldb-dev  On Behalf Of Nat! via lldb-
> dev
> Sent: Wednesday, March 6, 2019 8:47 AM
> To: lldb-dev@lists.llvm.org
> Subject: [EXT] [lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded
> 
> I couldn't figure out how to post a patch to reviews.llvm.org, so here it is 
> per
> email, with the hope that someone adopts it :)
> 
> Basically it's just moving the `bool print_oneline` out of the execution 
> path, if
> no children are
> 
> printed, since this value is then never used. This may not seem like a big 
> deal,
> but solves a big
> 
> problem in my debugger :)
> 
> 
> 
> ```
> 
> void ValueObjectPrinter::PrintChildrenIfNeeded(bool value_printed,
>     bool summary_printed) {
>    // this flag controls whether we tried to display a description for this
>    // object and failed if that happens, we want to display the children, if 
> any
>    bool is_failed_description =
>    !PrintObjectDescriptionIfNeeded(value_printed, summary_printed);
> 
>    auto curr_ptr_depth = m_ptr_depth;
>    bool print_children =
>    ShouldPrintChildren(is_failed_description, curr_ptr_depth);
> 
>    //
>    // DataVisualization::ShouldPrintAsOneLiner is often called for
>    // print_oneline (see below) and it is very expensive, so use an
>    // early exit, if we are not printing children (also easier to read)
>    //
>    if (!print_children) {
>      if (m_curr_depth >= m_options.m_max_depth && IsAggregate() &&
>     ShouldPrintValueObject()) {
>    m_stream->PutCString("{...}\n");
>      } else
>    m_stream->EOL();
>      return;
>    }
> 
>    //
>    // TODO: maybe move the bool print_oneline line to #1#, but its unclear to
>    // me if DataVisualization::ShouldPrintAsOneLiner can modify *m_valobj or
> not
>    //
>    bool print_oneline =
>    (curr_ptr_depth.CanAllowExpansion() || m_options.m_show_types ||
>     !m_options.m_allow_oneliner_mode || m_options.m_flat_output ||
>     (m_options.m_pointer_as_array) || m_options.m_show_location)
>    ? false
>    : DataVisualization::ShouldPrintAsOneLiner(*m_valobj);
> 
>    bool is_instance_ptr = IsInstancePointer();
>    uint64_t instance_ptr_value = LLDB_INVALID_ADDRESS;
> 
>    if (is_instance_ptr) {
>      instance_ptr_value = m_valobj->GetValueAsUnsigned(0);
>      if (m_printed_instance_pointers->count(instance_ptr_value)) {
>    // we already printed this instance-is-pointer thing, so don't expand 
> it
>    m_stream->PutCString(" {...}\n");
> 
>    // we're done here - get out fast
>    return;
>      } else
>    m_printed_instance_pointers->emplace(
>    instance_ptr_value); // remember this guy for future reference
>    }
> 
>    // #1#
>    if (print_oneline) {
>      m_stream->PutChar(' ');
>      PrintChildrenOneLiner(false);
>      m_stream->EOL();
>    } else
>      PrintChildren(value_printed, summary_printed, curr_ptr_depth); }
> 
> ```
> 
> 
> Ciao
> 
>     Nat!
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] When should ArchSpecs match?

2019-02-27 Thread Ted Woodward via lldb-dev
Hexagon uses “hexagon-unknown-elf” as its triple when running standalone (no 
OS) or with QuRT (our embedded OS), which expands to 
“hexagon-unknown-unknown-elf” sometimes, or “hexagon-unknown--elf” other times. 
For Linux we use “hexagon-unknown-linux”.

One issue I’ve seen is the Linux platform will match against 
“hexagon-unknown--elf”, so I need to make sure the Hexagon platform is in the 
plugin list before the Linux platform.

Ted

From: lldb-dev  On Behalf Of Greg Clayton via 
lldb-dev
Sent: Wednesday, February 27, 2019 4:15 PM
To: Zachary Turner 
Cc: ted.woodw...@codeaurora.org; LLDB 
Subject: [EXT] Re: [lldb-dev] When should ArchSpecs match?




On Dec 7, 2018, at 8:10 AM, Zachary Turner via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

“Unknown” is a perfectly fine value for the os though, and I’m not suggesting 
to change that.

My point is simply that Jason’s situation (baremetal) is one that is not even 
expressible by the Triple syntax. As long as there’s some enum value that 
describes the situation (of which unknown is a valid choice), the problem goes 
away.

We current use a "specified unknown" (where enum and string are unknown) to 
mean "none", which is what we use to say specify bare metal (no OS). I am happy 
to change that though. If we change this, then a few people's workflows might 
have to change where they used to say "armv7-apple-unknown" to 
"armv7-apple-none". Not a big deal since not many people are using LLDB for 
bare board debugging right now, but something we will need to document.

Greg



On Fri, Dec 7, 2018 at 8:06 AM 
mailto:ted.woodw...@codeaurora.org>> wrote:
We use 2 triples for Hexagon:
hexagon-unknown-elf (which becomes hexagon-unknown-unknown-elf internally), and 
hexagon-unknown-linux.

We follow the Linux standard and add in magic to the elf to identify it as a 
Linux binary. But in the hexagon-unknown-elf case we have no way to distinguish 
between standalone (no OS, running on our simulator) or QuRT (proprietary OS, 
could be running on hardware or simulator). In fact, the same shared library 
that has no OS calls (just standard library calls that go into the appropriate 
.so) could run under either one.

I think requiring a value for every OS would be a non-starter for us.

--
Ted Woodward
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

From: lldb-dev 
mailto:lldb-dev-boun...@lists.llvm.org>> On 
Behalf Of Zachary Turner via lldb-dev
Sent: Friday, December 7, 2018 4:38 AM
To: Pavel Labath mailto:pa...@labath.sk>>
Cc: LLDB mailto:lldb-dev@lists.llvm.org>>
Subject: Re: [lldb-dev] When should ArchSpecs match?

We can already say that with OSType::Unknown. That’s different than “i know 
that no OS exists”
On Fri, Dec 7, 2018 at 12:00 AM Pavel Labath 
mailto:pa...@labath.sk>> wrote:
On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote:
> Oh sorry I missed that.  Yes, I think a value added to the OSType for NoOS or 
> something would work.  We need to standardize on a textual representation for 
> this in a triple string as well, like 'none'.  Then with arm64-- and 
> arm64-*-* as UnknownVendor + UnknownOS we can have these marked as 
> "compatible" with any other value in the case Adrian is looking at.
>
>

Sounds good to me.

As another data point, it is usually impossible to tell from looking at
an ELF file which os it is intended to run on. You can tell the
architecture because it's right in the elf header, but that's about it.
Some OSs get around this by adding a special section like
.this.is.an.android.binary, but not all of them. So in general, we need
to be able to say "I have no idea which OS is this binary intended for".

pl
___
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [RFC]The future of pexpect

2019-02-21 Thread Ted Woodward via lldb-dev


> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Thursday, February 21, 2019 8:35 AM
> To: Davide Italiano 
> Cc: LLDB 
> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
> 
> On 21/02/2019 00:03, Davide Italiano wrote:
> > I found out that there are tests that effectively require
> > interactivity. Some of the lldb-mi ones are an example.
> > A common use-case is that of sending SIGTERM in a loop to make sure
> > `lldb-mi` doesn't crash and handle the signal correctly.
> >
> > This functionality is really hard to replicate in lit_as is_.
> > Any ideas on how we could handle this case?
> 
> How hard is it to import a new version of pexpect which supports python3 and
> stuff?
> 
> I'm not sure how the situation is on darwin, but I'd expect (:P) that most 
> linux
> systems either already have it installed, or have an easy way to do so. So we
> may not even be able to get away with just using the system one and skipping
> tests when it's not present.
> 
> BTW, for lldb-mi I would actually argue that it should *not* use pexpect :D.
> Interactivity is one thing, and I'm very much in favour of keeping that 
> ability,
> but pexpect is not a prerequisite for that. For me, the main advantage of
> pexpect is that it emulates a real terminal. However, lldb-mi does not need
> that stuff. It doesn't have any command line editing capabilities or similar. 
> It's
> expecting to communicate with an IDE over a pipe, and that's it.
> 
> Given that, it should be fairly easy to rewrite the lldb-mi tests to work on 
> top
> of the standard python "subprocess" library. While we're doing that, we might
> actually fix some of the issues that have been bugging everyone in the lldb-mi
> tests. At least for me, the most annoying thing was that when lldb-mi fails to
> produce the expected output, the test does not fail immediately, but instead
> the implementation of self.expect("^whatever") waits until the timeout
> expires, optimistically hoping that it will find some output that match the
> pattern.
> 
> If we change this to something like self.expect_reply("^whatever"), and make
> the "expect_reply" function smart enough to know that lldb-mi's response
> should come as a single line, and if the first line doesn't match, it should 
> abort,
> this problem would be fixed. While we're at it, we could also tune the failure
> message so that it's more helpful than the current implementation. Plus, that
> would solve the issue of not being able to run lldb-mi tests on windows.

This would be OK, I think, as long as "expect_reply" has the option to do a 
partial match,
or a regex match. Some of the lldb-mi tests only look for certain parts of the 
reply.

Also, until Python2 is declared dead and not supported at all by lldb, we 
should be able
to run this under 2 or 3.

> Anyway, that's what I'd do. I was actually planning to look into that soon, 
> but
> then I roped myself into writing a yaml (de)serialization tool for minidumps, 
> so
> I have no idea when I will get back to that. I hope some of this is helpful
> nonetheless.
> 
> cheers,
> pavel
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

2019-02-15 Thread Ted Woodward via lldb-dev
I don't see anything on this line that would change x:
   fprintf(stderr, "some string %lu %c\n",
r==(void*)0UL)? 255UL : A_MACRO(r),
x? '0' : '1'
  );

I suggest you set a breakpoint on the line and a breakpoint on the next line. 
Verify that x is the wrong value using "frame variable x" when you hit the 
second breakpoint.
Make sure this breakpoint is on a source line that does something, not in the 
middle of the function return.

If the value changes, disassemble the line and set a breakpoint on the call 
instruction for printf. See if the value changes when you hit that breakpoint.
If it does, look at the assembly and see if anything is changing the data at 
the address of x. You can get the address with "frame variable ".
If the call to printf is changing the value of x, you've probably got stack 
corruption going on.

---

Clang is supported on Linux:

>uname
Linux
>which clang
/usr/bin/clang

So you aren't forced to use gcc just because you're targeting Linux.

---

watchpoint set syntax is as follows:

(lldb) help watch set
 Commands for setting a watchpoint.

Syntax: watchpoint set  []


If you're setting it on a variable and you have good DWARF info, you don't need 
to specify a size. From my example:
> (lldb) w s v i
> Watchpoint created: Watchpoint 1: addr = 0x0410eec6 size = 2 state = 
> enabled type = w



-Original Message-
From: Jason Vas Dias  
Sent: Friday, February 15, 2019 10:33 AM
To: Ted Woodward 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] how to set a watchpoint on an "unsigned short" 
parameter ?

Good day Ted -

Thanks for responding - but I did try that one:

  (lldb) wa s v x
  error: Watchpoint creation failed (addr=0x, size=0, 
variable
expression='x').
  error: cannot set a watchpoint with watch_size of 0
  (lldb) wa s -s 2 v x
  invalid command 'watchpoint set -s'.
  (lldb) wa s v -s 2 x
  error: Watchpoint creation failed (addr=0x, size=0, 
variable
expression='x').
  error: cannot set a watchpoint with watch_size of 0

  I can't seem to get lldb to recognize the '-s' / '--size' options no matter
  where I put them .  And the documentation, such as it is,
  (on https://lldb.llvm.org/lldb-gdb.html), is very vague and incomplete.

  I guess my problems are  because I am  compiling with GCC , and trying
  to debug with LLDB .
  But since the program I am debugging is targetted mainly for the Linux 
platform,
  (I am just using MacOSX for testing) I wanted to compile with GCC .

  I guess it is not possible to debug GCC compiled programs with LLDB ?

  The problem I am trying to track down is stack corruption caused by
  fprintf() :

void f ( void *r, unsigned short x )
{  ...
   fprintf(stderr, "some string %lu %c\n",
r==(void*)0UL)? 255UL : A_MACRO(r),
x? '0' : '1'
  );
 // after this fprintf, the value of x changes from 12 to 8630 .
 // why ? It would be nice to be able to use LLDB to find out,
//  but this does not work.
}

 I've just had to comment out the fprintf , so the problem does not occur.

 Coming from a background of using GDB for the past 25 years, I find
 this lack of watchpoint support in LLDB very difficult to accept.

Thanks & Best Regards,
Jason






On 15/02/2019, Ted Woodward  wrote:
> "w s v x" would be the command you want.
>
>
> (lldb) b f
> Breakpoint 1: where = watch`f + 12 at watch.c:5:4, address = 
> 0x50ec
> (lldb) r
> hexagon-sim INFO: The rev_id used in the simulation is 0x4060
> (v60a_512)
> hexagon-sim INFO: Setting up debug server on port 57824 Process 1 
> launched: '/usr2/tedwood/lldb_test/watch' (hexagon) Process 1 stopped
> * thread #1, name = 'T1', stop reason = breakpoint 1.1
> frame #0: 0x50ec watch`f(i=2) at watch.c:5:4
>2
>3unsigned short f(unsigned short i)
>4{
> -> 5  i++;
>6  return i;
>7}
>8
> (lldb) w s v i
> Watchpoint created: Watchpoint 1: addr = 0x0410eec6 size = 2 state = 
> enabled type = w
> declare @ '/usr2/tedwood/lldb_test/watch.c:3'
> watchpoint spec = 'i'
> new value: 2
> (lldb) c
> Process 1 resuming
>
> Watchpoint 1 hit:
> old value: 2
> new value: 3
> Process 1 stopped
> * thread #1, name = 'T1', stop reason = watchpoint 1
> frame #0: 0x50f8 watch`f(i=3) at watch.c:6:10
>3unsigned short f(unsigned short i)
>4{
>5  i++;
> -> 6  return i;
>7}
>8
>9int main(int argc, char **argv)
>
>
>
> -Original Message-
> From: lldb-dev  On Behalf Of Jason 
> Vas Dias via lldb-dev
> Sent: Thursday, February 14, 2019 1:28 PM

Re: [lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

2019-02-15 Thread Ted Woodward via lldb-dev
"w s v x" would be the command you want.


(lldb) b f
Breakpoint 1: where = watch`f + 12 at watch.c:5:4, address = 0x50ec
(lldb) r
hexagon-sim INFO: The rev_id used in the simulation is 0x4060 (v60a_512)
hexagon-sim INFO: Setting up debug server on port 57824
Process 1 launched: '/usr2/tedwood/lldb_test/watch' (hexagon)
Process 1 stopped
* thread #1, name = 'T1', stop reason = breakpoint 1.1
frame #0: 0x50ec watch`f(i=2) at watch.c:5:4
   2   
   3unsigned short f(unsigned short i)
   4{
-> 5  i++;
   6  return i;
   7}
   8   
(lldb) w s v i
Watchpoint created: Watchpoint 1: addr = 0x0410eec6 size = 2 state = enabled 
type = w
declare @ '/usr2/tedwood/lldb_test/watch.c:3'
watchpoint spec = 'i'
new value: 2
(lldb) c
Process 1 resuming

Watchpoint 1 hit:
old value: 2
new value: 3
Process 1 stopped
* thread #1, name = 'T1', stop reason = watchpoint 1
frame #0: 0x50f8 watch`f(i=3) at watch.c:6:10
   3unsigned short f(unsigned short i)
   4{
   5  i++;
-> 6  return i;
   7}
   8   
   9int main(int argc, char **argv)



-Original Message-
From: lldb-dev  On Behalf Of Jason Vas Dias 
via lldb-dev
Sent: Thursday, February 14, 2019 1:28 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

Good day -

  I'd be most grateful if anyone could enlighten me as to how
  to set a watchpoint on an unsigned short parameter variable
  in lldb .

  I am trying to follow the instructions at :
https://lldb.llvm.org/lldb-gdb.html
  but they do not work to set watchpoints.

  There seems to be no other documentation for LLDB commands -
  or if anyone knows of any , please let me know.

  I have a function like :
void f ( unsigned short x )
{  }

  With the debugger stopped inside f, I have tried:

   (lldb)  p 
   (uint16_t *) $3 = 0x0001001122c0
   (lldb) wa s v -s 2 -w write 0x0001001122c0
   error: no variable named '0x0001001122c0' found in this frame
   (lldb) wa s v -s 2 -w write x
   error: Watchpoint creation failed (addr=0x, size=0, variable
   expression='x').
   error: cannot set a watchpoint with watch_size of 0
   (lldb) wa s e -s 2 -w write 0x0001001122c0
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write 0x0001001122c0
   (lldb) wa s e -s 2 -w write *0x0001001122c0
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write *0x0001001122c0
   (lldb) wa s e -s 2 -w write ((unsigned short*)0x0001001122c0)
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write ((unsigned short*)0x0001001122c0)
   (lldb) wa s v -s 2 -w write 
   error: 'x' doesn't have a valid address
   # ^- this error is really strange, particularly as I can do:
   (lldb) p 
   (uint16_t *) $5 = 0x0001001122c0

  It seems to me lldb's implementation of watch points is fundamentally broken -
  there is no way I've been able to get it to work .

  Unfortunately, I have to use MacOSX, so gdb is not available.

  Please, can anyone suggest how to successfully set a watchpoint on
  a parameter (stack) located variable value with lldb ?
  It does not seem to be possible.

  My next step, if no answers to this mail, would be to analyse the LLDB
  source code to see if I can figure out how watchpoints are meant to
  be set, seeing as there is no reference documentation for LLDB commands,
  either installed as manual pages or online.  This to me makes LLDB unsuitable
  for production use, but unforunately I have to use it (I need to debug under
  MacOSX 10,14.3 ).

   The help output for is of no use either:
   (lldb) help watch set
   "Syntax: watchpoint set  []
The following subcommands are supported:
  expression -- Set a watchpoint on an address by supplying an expression. 
Use the
  '-w' option to specify the type of watchpoint and the '-s'
option to specify the
  byte size to watch for.
"
The above statement is provably false:
 (lldb) wa s v -s 2 x
 error: Watchpoint creation failed (addr=0x, size=0,
   variable expression='x').
 error: cannot set a watchpoint with watch_size of 0
 # maybe the -s option goes after the 'set' ? no:
(lldb) wa s -s 2 v reader_id
invalid command 'watchpoint set -s'.

All attempts to
 "Use the '-w' option to specify the type of watchpoint and the '-s' option 
to
  specify the byte size to watch for.
 "
fail,  so there must be alot missing from the help description.

The help for the variable syntax is also vague, and provably false :
 "variable   -- Set a watchpoint on a variable. Use the '-w'
option to specify the type
 of watchpoint and the '-s' option to specify the byte size 
to watch for.
If no '-w' option is specified, it defaults to 

[lldb-dev] Odd intermittent test error

2019-02-08 Thread Ted Woodward via lldb-dev
Does anyone know what causes this? I see it on our bots intermittently, but 
haven't been able to reproduce it locally. The test passes, but something 
unnamed crashes, and the test is marked as failed.



 TEST 'lldb-Suite :: 
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py' FAILED 


...

PASS: LLDB 
(/local/mnt/workspace/bots/hexbotmaster-sles11_sd_0/hexagon-clang-83/build_tools/Tools/bin/clang-7-v67)
 :: test_with_run_command_dwarf (TestSyntheticCapping.SyntheticCappingTestCase)

...

--
Ran 4 tests in 0.225s
RESULT: PASSED (1 passes, 0 failures, 0 errors, 3 skipped, 0 expected failures, 
0 unexpected successes)
terminating with uncaught exception of type std::__1::system_error: mutex lock 
failed: Invalid argument

...




Failing Tests (1):

lldb-Suite :: 
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py

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


[lldb-dev] Problem with address breakpoints

2018-07-25 Thread Ted Woodward via lldb-dev
Hi Jim,

I found a breakpoint problem. Setting a breakpoint by address doesn't work
if the process isn't running. I traced it back to r322348, "Fix
Breakpoint::RemoveInvalidLocations to fix the exec testcase.", from January
11.

With ToT from a few days ago on x86_64 Linux, I get the address of main and
set a breakpoint:
(lldb) p main
(int (*)(int, char **)) $0 = 0x00400570
(lldb) b 0x400570
Breakpoint 1: address = 0x00400570

I run, it launches and runs to completion:
(lldb) r
Process 20293 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Factorial of 10 is 3628800
Process 20293 exited with status = 0 (0x)

Set a breakpoint by line, launch, and it stops:
(lldb) b 19
Breakpoint 2: where = factlin`main + 22 at factorial.c:32, address =
0x00400586
(lldb) r
Process 20352 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Process 20352 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 2.1
frame #0: 0x00400586 factlin`main(argc=1,
argv=0x7fffe218) at factorial.c:32
   29 }
   30   */
   31  
-> 32 base = 10;
   33  
   34 printf("Factorial of %d is %d\n", base, factorial(base));
   35 return 0;

Set the breakpoint by address while the process is running and run again.
This time it stops at the new address breakpoint.
(lldb) b 0x400570
Breakpoint 3: where = factlin`main at factorial.c:13, address =
0x00400570
(lldb) r
There is a running process, kill it and restart?: [Y/n] 
Process 20352 exited with status = 9 (0x0009) 
Process 20366 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Process 20366 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 3.1
frame #0: 0x00400570 factlin`main(argc=,
argv=) at factorial.c:13
   10   }
   11  
   12   int main(int argc, char **argv)
-> 13   {
   14 unsigned base;
   15  
   16   /*

Break list shows the first breakpoint as unresolved, and the third as
resolved.
(lldb) br l
Current breakpoints:
1: address = 0x00400570, locations = 1
  1.1: address = 0x00400570, unresolved, hit count = 0 

2: file = '/usr2/tedwood/lldb_test/factorial.c', line = 19, exact_match = 0,
locations = 1, resolved = 1, hit count = 1
  2.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 1 

3: address = factlin[0x00400570], locations = 1, resolved = 1, hit
count = 1
  3.1: where = factlin`main at factorial.c:13, address = 0x00400570,
resolved, hit count = 1



Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

2018-07-20 Thread Ted Woodward via lldb-dev
Instead of setting the sysroot, try the command

image search-paths add / /path/to/remote/shared/libraries/

 

That adds to the list that the dynamic loader uses to map shared object
paths.

 

It uses a simple text substitution, so in the above case,

/usr/lib/libc.so

Becomes

/path/to/remote/shared/libraries/usr/lib/libc.so

 

Matching up trailing slashes is critical, as I learned the hard way!

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene
Birukov via lldb-dev
Sent: Friday, July 20, 2018 1:13 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] LLDB does not respect platform sysroot when loading core
on Linux

 

Hello,

 

I would appreciate advise how to fix this correctly.

 

I have a core dump from somebody's RHEL Linux and I am trying to open it on
my Ubuntu. I have all the shared libraries from the target sitting under my
local directory. So, GDB happily opens the core after I issue "set sysroot
/path/to/local/root", but LLDB release_60 fails to do it.

 

I follow instructions from Greg's Clayton mail
http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html :

 

(lldb) platform select --sysroot /path/to/remote/shared/libraries
remote-linux

(lldb) 

 

Under debugger, I see that LLDB successfully created Platform object with
m_sdk_root set to my path and the Target uses it as its platform:

 

(gdb) p target_sp->m_platform_sp->m_sdk_sysroot

$42 = {

  m_string = 0x80e070 "/tmp/debugcore.3WyoW4/lib2"

}

 

But this value is not used when it comes to
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules. 

(gdb) bt

#0  lldb_private::ModuleList::GetSharedModule (module_spec=...,
module_sp=std::shared_ptr (empty) 0x0,

module_search_paths_ptr=0x83ad60, old_module_sp_ptr=0x7fffbb50,
did_create_ptr=0x7fffbb07,

always_create=false) at
/home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710

#1  0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &)
const (__closure=0x8581b0, spec=...)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234

#2  0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const
lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at
/usr/include/c++/5/functional:1857

#3  0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec
const&) const (this=0x7fffba80, __args#0=...) at
/usr/include/c++/5/functional:2267

#4  0x7fffedc3375a in
lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec
const&, lldb_private::Process*, std::shared_ptr&,
std::function
const&, bool*) (this=0x839330, module_spec=..., process=0x84d310,
module_sp=std::shared_ptr (empty) 0x0,

module_resolver=..., did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628

#5  0x7fffedc2d2cd in lldb_private::Platform::GetSharedModule
(this=0x839330, module_spec=...,

process=0x84d310, module_sp=std::shared_ptr (empty) 0x0,
module_search_paths_ptr=0x83ad60,

old_module_sp_ptr=0x7fffbb50, did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240

#6  0x7fffedc9957c in lldb_private::Target::GetSharedModule
(this=0x846960, module_spec=..., error_ptr=0x0)

at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952

#7  0x7fffef8e0d11 in lldb_private::DynamicLoader::LoadModuleAtAddress
(this=0x9a0a70, file=...,

link_map_addr=139700267943784, base_addr=139700263510016,
base_addr_is_offset=true)

at /home/eugene/llvm/tools/lldb/source/Core/DynamicLoader.cpp:171

#8  0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules
(this=0x9a0a70)

at
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/Dynamic
LoaderPOSIXDYLD.cpp:537

#9  0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (this=0x9a0a70)

at
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/Dynamic
LoaderPOSIXDYLD.cpp:171

#10 0x7fffedc476d9 in lldb_private::Process::LoadCore (this=0x84d310)

at /home/eugene/llvm/tools/lldb/source/Target/Process.cpp:2853

 

I simply do not see any reference to sysroot in the GetSharedModule() code.
What is there - it is only scanning module_search_paths_ptr looking for
file. This would not work because the scan ignores the directory part of the
module: it takes the next path from the list and appends the file name. What
I need instead - take m_sdk_sysroot from Platform and append the full module
- including directory - to it.

 

Unfortunately, GetSharedModule() is a static method and does not have any
clue what is current platform or current target. So, should I pass another
argument down there with sysroot or what? I have correct platform object at
frame 4.

 

Thanks,

Eugene

 

 


[lldb-dev] Top of tree lldb crashes running target modules dump symfile twice

2018-07-18 Thread Ted Woodward via lldb-dev
I have a very simple testcase, from the libc++ tests. get_id.pass.cpp.

#include 
#include 

int main()
{
std::thread::id id = std::this_thread::get_id();
std::thread::id id2 = std::thread::id();
assert(id != std::thread::id());
}

I built it with clang 3.8.0. I get the crash when I build it with g++ 4.8.4
as well.

% clang++ get_id.pass.cpp -o get_id.pass.cpp.exe -g -O0 -std=c++11
% lldb get_id.pass.cpp.exe
(lldb) b main
(lldb) run
(lldb) image dump symfile

(lldb) image dump symfile
Segmentation fault

Test was run on Ubuntu 14.04. The crash happens in TypeList::Dump

void TypeList::Dump(Stream *s, bool show_context) {
  for (iterator pos = m_types.begin(), end = m_types.end(); pos != end;
++pos) {
pos->get()->Dump(s, show_context);
  }
}

The call to Dump can change the vector, which makes the iterator invalid and
causes the crash when it's incremented. The change seems to happen in
SymbolFileDWARF::GetTypeForDIE.

The vector has a size of 8. Entries are:
"id"
"id"
"std::__1::__thread_id"
"std::__1::__thread_id"
"__thread_id"
"__thread_id"
"__libcpp_thread_id"
"__libcpp_thread_id"

The crash occurs when the 5th entry, the first "__thread_id", is dumped.
After the crash, the vector has 18 entries. The first 6 are the same as
before the Dump call that crashes.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Cannot install from source

2018-07-18 Thread Ted Woodward via lldb-dev
It should be built by the “lldb” target. What does that do?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of 
Quaquaraquà via lldb-dev
Sent: Wednesday, July 18, 2018 11:29 AM
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Cannot install from source

 

Indeed that folder is not present. Python 2.7 is installed and it is the 
default version of the system, I'm not changing its setting in the build.

On 18/07/18 18:19, Ted Woodward wrote:

When I do a build on Linux, in /lib I see a directory called python2.7, 
with a subdirectory site-packages. Do you not see this?

 

Are you building with a different python version than 2.7.x?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of nu 
quaquaraqua via lldb-dev
Sent: Wednesday, July 18, 2018 8:17 AM
To: lldb-dev@lists.llvm.org  
Subject: [lldb-dev] Cannot install from source

 

Dear folks,

 

I am trying to build & install LLVM, Clang and LLDB from source. Now the build 
completes fine, while the target `install' fails: 

 

-- Up-to-date: /opt/llvm/6.0.1/include/lldb/Host/Config.h

CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):

  file INSTALL cannot find "/opt/llvm/build/lib/python2.7".

Call Stack (most recent call first):

  tools/lldb/cmake_install.cmake:51 (include)

  tools/cmake_install.cmake:49 (include)

  cmake_install.cmake:65 (include)

 

 

make: *** [Makefile:140: install] Error 1

 

 

I am on branch `release 6.0', out of source build, all the defaults with the 
exception of the build type set to Release, custom prefix path, and target to 
build X86. The system is a Linux Fedora v28.

 

Suggestions on how to move on? :-)

Yours,

Quack

 

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


Re: [lldb-dev] Cannot install from source

2018-07-18 Thread Ted Woodward via lldb-dev
When I do a build on Linux, in /lib I see a directory called python2.7, 
with a subdirectory site-packages. Do you not see this?

 

Are you building with a different python version than 2.7.x?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of nu 
quaquaraqua via lldb-dev
Sent: Wednesday, July 18, 2018 8:17 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Cannot install from source

 

Dear folks,

 

I am trying to build & install LLVM, Clang and LLDB from source. Now the build 
completes fine, while the target `install' fails: 

 

-- Up-to-date: /opt/llvm/6.0.1/include/lldb/Host/Config.h

CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):

  file INSTALL cannot find "/opt/llvm/build/lib/python2.7".

Call Stack (most recent call first):

  tools/lldb/cmake_install.cmake:51 (include)

  tools/cmake_install.cmake:49 (include)

  cmake_install.cmake:65 (include)

 

 

make: *** [Makefile:140: install] Error 1

 

 

I am on branch `release 6.0', out of source build, all the defaults with the 
exception of the build type set to Release, custom prefix path, and target to 
build X86. The system is a Linux Fedora v28.

 

Suggestions on how to move on? :-)

Yours,

Quack

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


Re: [lldb-dev] error: process launch failed: Lost debug server connection

2018-07-09 Thread Ted Woodward via lldb-dev
FYI - the color you picked for this makes it unreadable against a white 
background. I had to convert it to plain text to read it.

 

The error message “Lost debug server connection” occurs if the platform isn’t 
connected and it is not a host platform.

 

What do you get if you type “platform status” after “file Test”?

 

Is the remote-built executable available on your Mac? lldb will need it to be 
able to get symbols and debug info.

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of NeckTwi 
via lldb-dev
Sent: Monday, July 09, 2018 1:27 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] error: process launch failed: Lost debug server connection

 

I have started lldb-server on remote linux in the directory where my executable 
need to be debugged reside.

>From my Mac I started lldb, 

(lldb) platform select remote-linux

  Platform: remote-linux

 Connected: no

(lldb) platform connect connect://pi.local:9091

  Platform: remote-linux

OS Version: 4.9.78 (4.9.78-v7+)

Kernel: #1084 SMP Thu Jan 25 18:05:49 GMT 2018

  Hostname: pi

 Connected: yes

WorkingDir: /Users/necktwi/Workspace/RemoteDebugTest/build

(lldb) file Test

Current executable set to ’Test' (arm).

(lldb) run

error: process launch failed: Lost debug server connection

 

Why the process launch failing? The executable `Test` takes parameters `-s 
normal`. How to feed them in? Did the process failed because of not feeding its 
arguments?

 

https://lldb.llvm.org/remote.html 

  explains how to debug a cross-built local executable on remote platform. But 
I am trying to debug the executable which was built on the remote.

 

Thank you.

 

… neckTwi



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


Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) - error: this file does not represent a loadable dylib

2018-06-08 Thread Ted Woodward via lldb-dev
Also try running
ldd 
/home/bkebianyor/eclipse-workspace/Model_LLDB_Debugger/Debug/libModel_LLDB_Debugger.so

That will list dependencies that the loader can and cannot resolve.

A possible alternative to a plugin could be to use "breakpoint set -p", which 
does a regular expression match on the source, so you can set a breakpoint 
based on the text of an annotation. You could wrap this in a python script if 
you want to make it into a custom command.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> Labath via lldb-dev
> Sent: Friday, June 08, 2018 5:13 AM
> To: bewoayia.kebian...@offis.de
> Cc: LLDB 
> Subject: Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) - error: 
> this file
> does not represent a loadable dylib
> 
> I would expect the issue is that dlopen fails to locate the dependent 
> libraries of
> your plugin. Can you lookup the actual dlopen call which opens your library 
> and
> see what is the exact error it fails with?
> On Fri, 8 Jun 2018 at 10:52, Bewoayia Kebianyor via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > Hello Everyone,
> >
> > I started looking into the LLDB with the intention of adding custom commands
> for my SW debugging purpose. For a better Understanding let me explain what
> I intend to do. I have an source file generated automatically from a Model 
> with
> certain anotations added as comments in the code. This code will would be
> compiled and in error cases debugged. When debugging I may have to set
> breakpoints at certain statements in the code based on the anotations incerted
> by the code generator. This is done by specifying the source file and the line
> number. I Use CLANG to get the line number and source file for the comments.
> >
> > I would like to have custom commands for this and internally map the to
> already existing commands  e.g. "breakpoint set -f -l". I found some examples
> for python, and for c++ I only found the example
> "lldb/examples/plugins/commands/fooplugin.cpp" for writing C++ plugin
> (dynLib) shipped with the LLDB source. In this example adding a new
> commands was straight forward and in the DoExecute function, I call the
> interpreter to handle a breakpoint command. I intend to use C++ rather than
> Python.
> >
> > This works fine for a simple shared lib (Simple modification of the Example
> provided in LLDB. In Do execute call interpreter to handle a breakpoint
> command). However if I add other C++ sources which does XML parsing,
> CLANG RecursiveASTVisitor etc to the Library, creating the shared library with
> eclipse is sucessful. I can link the created library to an application and it 
> works
> well. However when I load this in lldb with the command ==> plugin load
> "/home/bkebianyor/eclipse-
> workspace/Model_LLDB_Debugger/Debug/libModel_LLDB_Debugger.so", I get
> the error message: "error: this file does not represent a loadable dylib".
> >
> >
> > #Loading the shared lib that is linked just to the liblldb.so -
> > SUCESSFUL
> > (lldb)
> > (lldb) plugin load
> > /home/bkebianyor/eclipse-workspace/DynLib/Debug/libDynLib.so
> > (lldb)
> >
> > #Loading the shared lib that is linked just to the liblldb.so +
> > libxerces-c-3.2.so - FAILS
> >
> > (lldb) plugin load  "/home/bkebianyor/eclipse-
> workspace/Model_LLDB_Debugger/Debug/libModel_LLDB_Debugger.so"
> > error: this file does not represent a loadable dylib
> >
> > I have searched for this error on google, but could not find out how to 
> > resolve
> this error. Most answers pointed to a mismatch of the lldb version in the 
> shared
> lib to be loaded and that linked to lldb, but that is not my case. I am using 
> lldb-
> 5.0.2 and LLVM/CLANG 5.0.2 toolcahin on Linux 16.04.1-Ubuntu and Eclipse
> IDE. LLVM was built with SHARED_LIBS set to ON.
> >
> > Would be grateful for an answer.
> >
> >
> > Thanks and Regards,
> >
> > Bewoayia
> >
> > -
> > Dipl.- Ing. Bewoayia Kebianyor
> > Researcher - Hardware/Software Design Methodology Group
> >
> > OFFIS e.V. - Institut für Informatik
> > FuE Bereich Verkehr | R Division Transportation Escherweg 2 - 26121
> > Oldenburg - Germany
> > Phone/Fax.: +49 441 9722 237/-278
> > E-Mail: bewoayia.kebian...@offis.de
> > URL: http://www.offis.de
> >
> > Registergericht: Amtsgericht Oldenburg VR 1956
> > Vorstand: Prof. Dr.-Ing. Wolfgang H. Nebel (Vorsitzender), Prof. Dr.
> > techn. Susanne Boll-Westermann, Prof. Dr. Werner Damm, Prof. Dr.-Ing.
> > Axel Hahn, Prof. Dr.-Ing. Andreas Hein, Prof. Dr. Sebastian Lehnhoff
> > ___
> > 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
> 

Re: [lldb-dev] Advice on architectures with multiple address spaces

2018-05-25 Thread Ted Woodward via lldb-dev
You can conceptually take this a step further. I used to work at Freescale, and 
supported SoCs with multiple heterogeneous cores. I provided memory spaces that 
let the user access these memory views:

- DCSR (debug memory, a separate bus) through the SoC
- CCSR (memory mapped config registers) through the SoC
- cache coherent physical access through the SoC
- uncached physical access through the SoC
- virtual access through a given core (PPC or StarCore)
- cache coherent physical access through a given core
- uncached physical access through a given core

I also provided a cache view which would allow the user to read/modify data and 
tag/status of the L1i, L1d, L2 and L3 caches.

Basically, let the user access memory (whether it was RAM, memory mapped 
registers, or something else) any way he or she wants. What the core sees, what 
the SoC sees, cacheable, uncached (so, in the backing store), or what's in the 
caches.

Once you have memory space support, you can make arbitrary spaces that show you 
whatever you want.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Duane
> Ellis via lldb-dev
> Sent: Friday, May 25, 2018 9:40 AM
> To: Zdenek Prikryl 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Advice on architectures with multiple address spaces
> 
> As an FYI - this is another way of looking at Address spaces.. I like the word
> “Route” to the memory space, i think it defines the problem better.
> 
> All Armv8 chips effectively have - multiple address available to the debugger
> 
> For instance, a JTAG debugger halts an ARMV8 cpu core, and the core halts in
> user space - the question is what are the various address spaces a developer
> might want to dump memory for:
> 
> A) The current user space view of memory - to print a user space variable.
> 
> B) The current Kernel (OS) view of memory - perhaps to print data structure in
> kernel space
> 
> C) At the hypervisor level which is the core’s view of physical memory - 
> perhaps
> the developer wants to examine a data structure or variable in the hypervisor.
> 
> D) The ARM dap - has 3 (sometime 4) memory bus interfaces. They are
> typically:
> 
> Dap Port 0 - is typically the main system bus, often the same as the CPU’s
> connection to the main system bus but not exactly
> 
> ie: CPU access to a multi-media bus, via a dedicated connection/address range,
> in contrast the  main system bus has a different connection/route to the
> multimedia memory
> 
> Dap Port 1 - commonly provides access to various Coresight items for most of
> the cores.
> 
> Dap Port 2 - Varies - it could be an embedded Jtag controller - say with an
> ARM9 or other JTAG only interface)
> 
> Dap Port 3 - Varies - But often there are a few CORTEX M series CPUs - and I
> believe each M3 on the target must have its own dedicated DAP interface.
> 
> Assume for a moment, each of these address spaces have a name, there is the
> default, then there needs to be various override methods
> 
> Being able to some how specify these different “access routes” is helpful when
> debugging hardware at the bare metal level.
> 
> In the above, I’m not talking about looking at a complex variable (that would 
> be
> really nice, ie: cast a memory address to a fancy type)
> 
> When debugging a SYSTEM - this becomes very important.  Minimally being
> able to have a “memory window” that can specify the route is helpful - for
> example
> 
>   Dump Memory at :  HyperVisor address 0x12345678
>   Dump Memory at:  Kernel address  0x45678901234
>   Dump Memory using the system bus interface
> 
> Across multiple cores - you have
> 
> 1) Some very common routes - ie: “In the current context” vrs “Kernel context”
> These should have commonly defined names.
> 
> 2) Some platforms may need to add their own “platform defined” items (ie:
> various armv8 routes would be semi-common)
> 
> 3) Some VERY specific routes or methods that are developer defined - For
> example when accessing memory via the DAP MEM_AP, there are special bits
> in the control register (controlling security and/or cache control). Maybe the
> developer needs to set those a special way when performing the memory
> access when using this “route”
> 
> The lauterbach jtag debugger can do the above now (it is an address prefix)
> The ARM debugger (If I remember correctly) can also do this somewhere in its
> script language.
> 
> But tools like GDB and LLDB can not
> 
> Because tools like GDB and LLDB have a scripting language (ie: Python) - being
> able to write a script in that scripting language and be able to specify the
> ROUTE is important.
> 
> For example, a script that writes to a bunch of hardware locations via the
> MEMAP (or possibly via different CPU) - to enable a feature so that you can 
> 

Re: [lldb-dev] Welcome Alexander!

2018-04-24 Thread Ted Woodward via lldb-dev

You'll still need HandleCommand for pass through commands. lldb commands send 
to lldb-mi are handled normally, so something like "file a.out" would set up a 
target using a.out. "-interpreter exec console " does the same thing. 
Other than that, I'm all for cleaning up lldb-mi. There were some funky 
decisions made when it was first developed.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Tuesday, April 24, 2018 5:19 PM
> To: Greg Clayton 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Welcome Alexander!
> 
> 
> 
> > On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> >>
> >>
> >>
> >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
> >>>
> >>>
> >>>
>  On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
> 
> 
> 
> > On Apr 24, 2018, at 9:44 AM, Greg Clayton 
> wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 9:37 AM, Jim Ingham 
> wrote:
> >>
> >>>
> >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev  d...@lists.llvm.org> wrote:
> >>>
> >>> Welcome Alexander!
> >>
> >> Yes, welcome!
> >>
> >>>
> >>> The title might be more stated as "Reimplement lldb-mi to correctly
> use the SB API instead of using HandleCommand and regular expressions to
> parse the command results" as it is already using the SB API, just not using 
> it
> anywhere close to correctly!
> >>>
> >>> I look forward to seeing the changes.
> >>>
> >>> A few things I ran into when playing with lldb-mi:
> >>> - file-exec or exec-file packet might come _after_ some breakpoints
> are set. We should make sure we create a lldb::SBTarget right away and set the
> breakpoints on the empty target so that we don't miss these breakpoints if 
> this
> is still an issue. Then the when we receive the exec-file packet, we set the 
> file
> on the target
> >>
> >> Breakpoints set before any target is created are set on the dummy
> target.  Breakpoints on the dummy target are copied into any new targets.  So
> this should not be necessary.  If that wasn't working we should figure that 
> out,
> but it's not the responsibility of the MI to get this right.
> >
> > We are trying not to use the command line and the command line is
> what uses the dummy target automatically. When using the SB API you use a
> lldb::SBTarget to set the breakpoint on so you need a target. What do you
> suggest we use for the target? I would rather the lldb-mi code not rely on the
> currently selected target or the dummy target.
> 
>  lldb-MI models gdb's behavior, which is one debugger with one target.
> There is no command to add or switch to targets, etc.  So it doesn't seem
> unreasonable for MI to keep track of its one actual target and if that is 
> empty,
> use SBDebugger::GetDummyTarget.  The other option is to make a blank target
> up front and then add files to it when you see the -file-exec command. But 
> that
> seems more error-prone than using the mechanism lldb provides for doing
> things before you have a target.  Again, if we were modeling an API that could
> switch targets we might want to do something more clever.  But that isn't how
> the GDB-MI was set up to work.
> 
> >>>
> >>> lldb-mi code may or may not have a target when it needs one. If it doesn't
> have a target, use the SB API to get the dummy target and use that.
> >>>
> >>> Jim: is the dummy target good for anything other than adding breakpoints
> to? What all gets copied from a the dummy target to the new target when one
> gets created?
> >>
> >> At present it only does breakpoints and stop hooks (see
> Target::PrimeFromDummyTarget.)  I didn't do watchpoints since those are
> seldom things you want to set generically, but you could probably add that.
> Was there anything else you were thinking of?
> >>
> >
> > No, just mostly trying to let Alexander know what he should use the Dummy
> target for and also for my own knowledge. If there are MI clients that do 
> other
> things, we will need to know if we need to create an empty real target if they
> aren't breakpoints or stop hooks.
> 
> I can't think of any other things you add to a target like this.  The 
> settings get
> inherited, and once you've started adding modules, I think you should create a
> new target to hold them.  But for anything interesting that's missing, as 
> long as
> they are copiable it would be easy to add them.  Just call
> GetSelectedOrDummyTarget when you go to set them, and then put the copy in
> PrimeFromDummyTarget.
> 
> >
> > Greg
> >
> >> Jim
> 

Re: [lldb-dev] problems running the LLDB lit tests on Windows

2018-04-20 Thread Ted Woodward via lldb-dev
See my comment in https://reviews.llvm.org/D45333 .

 

r330275 changed how lldb’s lit tests were set up. This gives cmake errors using 
the Visual Studio generator; I wouldn’t be surprised if what you’re seeing 
using ninja is the same issue.

 

Short version: the cmake code that sets up the lit config in lldb is different 
from the cmake code that sets up the lit config in clang. This is causing the 
VS generator errors, and might be causing your problems with ninja.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Adrian 
McCarthy via lldb-dev
Sent: Friday, April 20, 2018 1:21 PM
To: LLDB 
Subject: [lldb-dev] problems running the LLDB lit tests on Windows

 

I'm trying to figure out what's happening with the LLDB lit tests on Windows.  
I'm not sure how to proceed with debugging this.

 

I execute this command:

 

  ninja check-lldb

 

And several things happen very rapidly:

 

1.  On the console, I get one warning that says:

 

D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\discovery.py:121: 
ResourceWarning: unclosed file <_io.BufferedReader name=3>

key = (ts, path_in_suite)

  

2.  Then I get several dozen messages of this form:

 

D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\TestRunner.py:727: 
ResourceWarning: unclosed file <_io.BufferedReader name=6>

res = _executeShCmd(cmd.rhs, shenv, results, timeoutHelper)

  

3.  I get more than 200 dialog boxes that are essentially assertion failures in 
the CRT implementation of `close`.  The line complained about in the dialog is:

  

_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), 
EBADF, -1);

  

where `fh` is the value passed to `close`.  Indeed, `fh` typically has a value 
like 452 which is not in the range of 0 to `_nhandle` because `_nhandle` is 64.

 

Starting from 3, I tried to walk up the stack to see what's going on, but it's 
just the generic workings of the Python virtual machine.  The `close` call is 
happening because something in the .py code is calling `close`.  It's hard to 
see the Python code in the debugger.  It doesn't actually seem to be test code.

 

So I checked out the command line for one of those asserting processes to see 
if I could figure out which tests are exhibiting the problem.

 

"C:\python_35\python_d.exe" "-R" "-c" "from multiprocessing.spawn import 
spawn_main; spawn_main(pipe_handle=992, parent_pid=32640)" 
"--multiprocessing-fork"



The `pipe_handle` value does not correspond to the value being passed to the 
`close`.  The `parent_pid` always refers to the parent lit command.

 

There always seem to be 32 Python processes in this state.  If I kill one, 
another is immediately spawned to replace it (creating a new assertion failure 
dialog).  I'm guessing that if I continued, there would be one for each test, 
and that somewhere there's a limit of 32 processes at a time.

 

So this kind of sounds like a lit bug, but other lit tests (as in `ninja 
check-llvm`) run just fine.  So it has something to do with how we invoke lit 
for LLDB.  The command being executed, per the build.ninja file, is:

 

cd /D D:\src\llvm\build\mono\tools\lldb\lit && C:\python_35\python_d.exe 
D:/src/llvm/build/mono/./bin/llvm-lit.py -sv --param 
lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg --param 
lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg 
D:/src/llvm/build/mono/tools/lldb/lit

 

The LLDB-specific things in the command are lit configs, with which I've been 
blissfully ignorant.  Should I head down that rabbit hole?  Could this be a 
problem with my environment?

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


[lldb-dev] r329889 - Use in-tree dsymutil on Darwin

2018-04-20 Thread Ted Woodward via lldb-dev
r329889 says "Use in-tree dsymutil on Darwin", but it's got these change in
test/CMakeLists.txt:
-set(LLDB_TEST_DEPS lldb)
+set(LLDB_TEST_DEPS lldb dsymutil)

...

+  --dsymutil $


These changes aren't gated by a check for Darwin, so they happen on all
systems. On my machine (Ubuntu 14), which doesn't have dsymutil, cmake
generation gives errors about missing dependency dsymutil.

CMake Error at tools/lldb/test/CMakeLists.txt:161 (add_dependencies):
   The dependency target "dsymutil" of target "lldb-dotest" does not exist.

Jonas, can you gate those changes with a check for Darwin, which is the
intention of the patch?

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Proposal: Using LLD in tests

2018-04-19 Thread Ted Woodward via lldb-dev

Our Windows buildbots use msys for gnuisms. The makefiles in the test suite run 
fine with minimal modifications (just the object delete hack Zach put in to use 
del instead of rm; msys make doesn't accept cmd syntax while Cygwin make does). 
Now, that's using clang to build Hexagon binaries, but teaching the makefile to 
use cl syntax shouldn't be too hard. I've seen it done before; same makefile 
for windows and various unix derivatives, detect what OS you were running on 
and set CFLAGS/CXXFLAGS/LDFLAGS accordingly.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> Labath via lldb-dev
> Sent: Thursday, April 19, 2018 12:45 PM
> To: Leonard Mosescu 
> Cc: aaron.lee.sm...@gmail.com; LLDB 
> Subject: Re: [lldb-dev] Proposal: Using LLD in tests
> 
> On Thu, 19 Apr 2018 at 18:19, Leonard Mosescu 
> wrote:
> 
> >>the PDB tests under lit/SymbolFile/PDB need a linker to produce
> >> the
> program database
> 
> 
> > With this proposal, would we preserve any coverage for MSVC produced
> debug information?
> 
> 
> Well.. the question there is what are you trying to test? Is it the fact your
> debugger works with a particular compiler+linker combination (note that those
> tests already compile with clang-cl), or that your pdb-parsing code is sane.
> (integration vs. regression test).
> 
> Historically we've only had the former kind of tests (dotest), and we've had 
> the
> ability (and used it) to run those tests against different kinds of 
> compilers. This
> is all nice, but it means that a specific test will be testing a different 
> thing for
> every person who runs it. That's why I would like to build up a suite of more
> regression-like tests (*). I would say that the tests under lit/*** should be
> regression tests and our goal should be to remove as many system
> dependencies as possible, and leave the job of testing integration with a
> specific toolchain to "dotest" tests (**).
> 
> Technically, the answer to your question is "no", because currently dotest 
> tests
> don't know how to work with cl+link. Making that work would be an interesting
> project (although a bit annoying as the Makefiles are full of gcc-isms).
> However, I don't think that should stop us here.
> 
> (*) Ideally I would like to leave even the compiler out of the equation for 
> these
> tests, and make it so that the tests always run on the exact same set of 
> bytes. I
> am hoping I will be able to write at least some tests using .s files. 
> However, I
> don't think I will do that for all of them, because these files can be
> long/verbose/tedious to write.
> 
> (**) However, even "dotest" tests should have a "default" mode which is as
> hermetic as possible.
> ___
> 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] Advice on architectures with multiple address spaces

2018-04-19 Thread Ted Woodward via lldb-dev

Hexagon has a single address space, so we don't need to do anything like this.

When I worked on Motorola 56xxx DSPs we had memory spaces, but we didn't use 
RSP. We had our own protocol that used a struct for addreses, with the space 
(an enum, defined per supported core) and a uint32_t (later 2 of them) for the 
address.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Thursday, April 19, 2018 11:45 AM
> To: Zdenek Prikryl 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Advice on architectures with multiple address spaces
You might ask
> the Hexagon folks if they have done anything in case they already support this
> is some shape or form.
> 
> Greg Clayton
> 



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


Re: [lldb-dev] Can I call a python script from LLDB c++ code?

2018-04-03 Thread Ted Woodward via lldb-dev
Responses inline

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: Greg Clayton [mailto:clayb...@gmail.com]
> Sent: Tuesday, April 03, 2018 5:19 PM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Can I call a python script from LLDB c++ code?
> 
> 
> 
> > On Apr 3, 2018, at 12:18 PM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > LLDB for Hexagon can automatically launch and connect to the Hexagon
> > simulator, much like LLDB can launch and connect to debugserver/lldb-
> server.
> > I've got a copy of GDBRemoteCommunication::StartDebugserverProcess
> > that does this. A copy because there are feature incompatibilities
> > between hexagon-sim and debugserver/lldb-server.
> >
> > On a hardware target, our OS has a debug stub. We'd like to run the
> > lldb test suite talking to this stub on the simulator, instead of
> > talking to the RSP interface the simulator publishes. We have a module
> > that will forward ports to the OS under simulation, but to do this I
need to:
> > 1) open an http connection to port x
> > 2) parse some xml coming back that contains the actual port for the
> > stub I want to connect to
> > 3) connect to the new port
> 
> 
> Can't you forward ports in advance and then run lldb-server in platform
mode
> and tell it to use only those ports? Then lldb-server will do everything
it needs.
> There is a port offset option to lldb-server that can be used in case the
lldb-
> server that runs on the simulator returns say port , but it needs to
have
> 1 added to it...

Short answer - no.  It's a custom stub, not lldb-server, but that's not the
issue.
The issue is that the mechanism to get data into the simulation mimics what
we do on
hardware, where the DSP doesn't have access to the outside world, and
everything
goes through an Android app. The system publishes 1 port per process that
the stub
controls. These ports are picked randomly, and are set up when the http
connection
is made. The data that is read over that connection needs to be parsed to
find the
ports that the stub is publishing.

> > I have a python script that will do this, but I need to do it inside
> > LLDB
> > c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will
> > c++ jump
> > through the correct hoops and connect to the stub under simulation.
> >
> > Is there a good way to call a python script from LLDB c++ code and get
> > a result back? Or is there a better solution?
> >
> 
> The the main question is can you run lldb-server in the simulator and have
the
> test suite just work? What is stopping you from being able to do that if
the
> answer is no?

I've got the test suite working using the simulator's RSP interface, but the
next step
is to exercise the OS stub. And to get to it I have to jump through the
hoops I talked
about earlier.

> It sounds like a real hack if you have to run a python script in
> ProcessGDBRemote. It sounds like you need to just modify your hexagon
> simulator platform code to "do the right thing".

"Do the right thing" in this case involves opening an http connection,
parsing XML,
and telling LLDB to connect to the port I get from the XML. The launch is
done inside
Process::Launch, which is called from the platform, so I can't do any
processing
In the platform.

Worst case I could do something like 'system("python sim_stub_connect.py")'
to get the port
that's being published, if using LLDB's interpreter is not a good idea.

> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >
> > ___
> > 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] Can I call a python script from LLDB c++ code?

2018-04-03 Thread Ted Woodward via lldb-dev
LLDB for Hexagon can automatically launch and connect to the Hexagon
simulator, much like LLDB can launch and connect to debugserver/lldb-server.
I've got a copy of GDBRemoteCommunication::StartDebugserverProcess that does
this. A copy because there are feature incompatibilities between hexagon-sim
and debugserver/lldb-server.

On a hardware target, our OS has a debug stub. We'd like to run the lldb
test suite talking to this stub on the simulator, instead of talking to the
RSP interface the simulator publishes. We have a module that will forward
ports to the OS under simulation, but to do this I need to:
1) open an http connection to port x
2) parse some xml coming back that contains the actual port for the stub I
want to connect to
3) connect to the new port

I have a python script that will do this, but I need to do it inside LLDB
c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will jump
through the correct hoops and connect to the stub under simulation.

Is there a good way to call a python script from LLDB c++ code and get a
result back? Or is there a better solution?

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

2018-03-30 Thread Ted Woodward via lldb-dev
You might not need non-stop mode to debug both the CPU and GPU. We did a 
similar thing, using lldb to debug an Android app and an app running on the 
Hexagon DSP under Linux. We didn’t use the same lldb, but that’s because 
Android Studio doesn’t know about Hexagon. The Android app was debugged with 
Android Studio’s lldb, and in Android Studio we opened a console window and 
ssh’d to Hexagon Linux, where we ran lldb (yes, Greg, lldb under Linux on the 
DSP!). We were able to debug the interaction between the CPU and DSP.

 

The reason I say you might not need non-stop mode is another DSP use case. On 
our proprietary DSP OS, the debug agent doesn’t stop all threads in a process 
when one thread stops. Even though lldb acts like all threads are stopped, only 
one stopped and the others are still running. As long as the stub doesn’t error 
out when lldb checks the other threads, lldb will behave correctly. If another 
thread hits a breakpoint while the current one is stopped, the stub waits until 
it gets a resume to send the stop-reply. So lldb thinks everything is stopped, 
but it’s not really.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Ramana via 
lldb-dev
Sent: Friday, March 30, 2018 12:29 PM
To: Frédéric Riss 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

 

> I’m not sure why Ramana is interested in it

Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html is 
what I am trying to implement in lldb which has been discussed in little more 
details here 
http://lists.llvm.org/pipermail/lldb-dev/2017-September/012815.html. 

 

On Thu, Mar 29, 2018 at 9:40 PM, Frédéric Riss  > wrote:





On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev  > wrote:

 

 





On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev  > wrote:

 

Hi,

It appears that the lldb-server, as of v5.0, did not implement the GDB RSPs 
non-stop mode 
(https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop).
 Am I wrong?

If the support is actually not there, what needs to be changed to enable the 
same in lldb-server?

 

As Pavel said, adding support into lldb-server will be easy. Adding support to 
LLDB will be harder. One downside of enabling this mode will be a performance 
loss in the GDB remote packet transfer. Why? IIRC this mode requires a read 
thread where one thread is always reading packets and putting them into a 
packet buffer. Threads that want to send a packet an get a reply must not send 
the packet then use a condition variable + mutex to wait for the response. This 
threading overhead really slows down the packet transfers. Currently we have a 
mutex on the GDB remote communication where each thread that needs to send a 
packet will take the mutex and then send the packet and wait for the response 
on the same thread. I know the performance differences are large on MacOS, not 
sure how they are on other systems. If you do end up enabling this, please run 
the "process plugin packet speed-test" command which is available only when 
debugging with ProcessGDBRemote. It will send an receive various packets of 
various sizes and report speed statistics back to you.



 

Also, in lldb at least I see some code relevant to non-stop mode, but is 
non-stop mode fully implemented in lldb or there is only partial support?

 

Everything in LLDB right now assumes a process centric debugging model where 
when one thread stops all threads are stopped. There will be quite a large 
amount of changes needed for a thread centric model. The biggest issue I know 
about is breakpoints. Any time you need to step over a breakpoint, you must 
stop all threads, disable the breakpoint, single step the thread and re-enable 
the breakpoint, then start all threads again. So even the thread centric model 
would need to start and stop all threads many times. 

 

If we work on this, that’s not the way we should approach breakpoints in 
non-stop mode (and it’s not how GDB does it). I’m not sure why Ramana is 
interested in it, but I think one of the main motivations to add it to GDB was 
systems where stopping all some threads for even a small amount of time would 
just break things. You want a way to step over breakpoints without disrupting 
the other threads.

 

Instead of removing the breakpoint, you can just teach the debugger to execute 
the code that has been patched in a different context. You can either move the 
code someplace else and execute it there or emulate it. Sometimes you’ll need 
to patch it if it is PC-relative. IIRC, GDB calls this displaced stepping. It’s 
relatively 

Re: [lldb-dev] increase timeout for tests?

2018-03-14 Thread Ted Woodward via lldb-dev
I don't see 22 lldb-mi tests xfailed everywhere. I see a lot of tests skipped, 
but
those are clearly marked as skip on Windows, FreeBSD, Darwin, Linux. I've got
a good chunk of the lldb-mi tests running on Hexagon. I don’t want them deleted,
since I use them.

lldb-mi tests can be hard to debug, but I found that setting the lldb-mi log to 
be
stdout helps a lot. In lldbmi_testcase.py, in spawnLldbMi, add this line:

self.child.logfile = sys.stdout

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Vedant
> Kumar via lldb-dev
> Sent: Tuesday, March 13, 2018 7:48 PM
> To: Davide Italiano 
> Cc: LLDB 
> Subject: Re: [lldb-dev] increase timeout for tests?
> 
> As a first step, I think there's consensus on increasing the test timeout to 
> ~3x
> the length of the slowest test we know of. That test appears to be
> TestDataFormatterObjC, which takes 388 seconds on Davide's machine. So I
> propose 20 minutes as the timeout value.
> 
> Separately, regarding x-failed pexpect()-backed tests, I propose deleting them
> if they've been x-failed for over a year. That seems like a long enough time 
> to
> wait for someone to step up and fix them given that they're a real
> testing/maintenance burden. For any group of to-be-deleted tests, like the 22
> lldb-mi tests x-failed in all configurations, I'd file a PR about potentially
> bringing the tests back. Thoughts?
> 
> thanks,
> vedant
> 
> > On Mar 13, 2018, at 11:52 AM, Davide Italiano 
> wrote:
> >
> > On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham 
> wrote:
> >> It sounds like we timing out based on the whole test class, not the 
> >> individual
> tests?  If you're worried about test failures not hanging up the test suite 
> the you
> really want to do the latter.
> >>
> >> These are all tests that contain 5 or more independent tests.  That's
> probably why they are taking so long to run.
> >>
> >> I don't object to having fairly long backstop timeouts, though I agree with
> Pavel that we should choose something reasonable based on the slowest
> running tests just so some single error doesn't cause test runs to just never
> complete, making analysis harder.
> >>
> >
> > Vedant (cc:ed) is going to take a look at this as he's babysitting the
> > bots for the week. I'll defer the call to him.
> 
> ___
> 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] tests xfailed globally with radar references

2018-03-13 Thread Ted Woodward via lldb-dev
I was investigating TestWatchedVarHitWhenInScope.py, which tests that a
watchpoint is hit in scope and not hit when out of scope. It's xfailed due
to a radar:
@unittest2.expectedFailure("rdar://problem/18685649")

This is an actual bug - watchpoints are hit when the address is modified but
the variable is out of scope. Which can happen a lot if the variable being
watched is a local on the stack. I manually ran the testcase on Linux, and
it failed when it hit the watchpoint out of scope:
Process 18652 stopped
* thread #1, name = 'a.out', stop reason = watchpoint 1
frame #0: 0x7722d0d2 libc.so.6`__run_exit_handlers(status=0,
listp=0x775b36c8, run_list_atexit=true) at exit.c:35

A google search found this message, posted by Ed Maste to llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116471.html .

I echo Ed's request - could someone at Apple look at these radars, and open
llvm bugs for the ones that aren't Darwin-only?


Ed's message:

I was recently looking at an unexpected pass test result on FreeBSD[1]
which is decorated with expectedFailureAll referencing
rdar://problem/24599697. I'm looking for more details on this specific
radar bug report in order to determine if the test is not exercising
the original bug on FreeBSD, or if it's really an Apple-only issue.

As it's rather unfortunate to have a bug report reference for which no
further public details are available I looked at other radar
references in the test suite, and found 118 of them. Many of these are
in comments, in macosx-specific cases (e.g.
@expectedFailureAll(oslist=["macosx"], bugnumber="rdar://28805064")),
or in tests decorated with skipUnlessDarwin, and I've ignored those.

There are 10 tests with expected failure decorators, and one skipped,
that apply beyond macosx and reference a radar (and do not
additionally reference an LLVM PR). Can someone at Apple check these
radar references and submit LLVM PRs, reference existing PRs, add a
reasonable description in the test source, etc. as appropriate?

functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScop
e.py
unittest2.expectedFailure("rdar://problem/18685649")

functionalities/asan/TestReportData.py
@expectedFailureAll(archs=['i386'], bugnumber="rdar://28658860")

api/multiple-debuggers/TestMultipleDebuggers.py
@expectedFailureAll(bugnumber="rdar://30564102")

lang/objc/bitfield_ivars/TestBitfieldIvars.py
decorators.expectedFailureAll(bugnumber="rdar://problem/17990991")])

lang/c/shared_lib/TestSharedLib.py
@unittest2.expectedFailure("rdar://problem/10704639")

lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
@unittest2.expectedFailure("rdar://problem/10381325")

lang/cpp/stl/TestSTL.py
@expectedFailureAll(bugnumber="rdar://problem/10400981")

lang/cpp/dynamic-value/TestCppValueCast.py
@unittest2.expectedFailure("rdar://problem/10808472 SBValue::Cast test
case is failing (virtual inheritance)")

lang/cpp/printf/TestPrintf.py
decorators.expectedFailureAll(bugnumber="rdar://problem/24599697")])

lang/cpp/function-template-parameter-pack/TestFunctionTemplateParameterPack.
py
decorators.expectedFailureAll(bugnumber="rdar://problem/32096064")])

lang/cpp/unique-types/TestUniqueTypes.py
self.skipTest("rdar://problem/9173060 lldb hangs while running
unique-types for clang version < 3")

[1]
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20170807/036634.htm
l

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'

2018-03-09 Thread Ted Woodward via lldb-dev
Also see http://llvm.org/docs/Contributing.html 

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide
> Italiano via lldb-dev
> Sent: Friday, March 09, 2018 10:27 AM
> To: Timothee Cour 
> Cc: LLDB 
> Subject: Re: [lldb-dev] how do i submit my patch for 'Support demangling for D
> symbols via dlopen'
> 
> On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev  d...@lists.llvm.org> wrote:
> > I've registered to
> > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent
> > my patch via that email to lldb-comm...@lists.llvm.org but doesn't
> > appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how long
> > does it take for
> > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits to
> > subscribe?
> >
> 
> Again, please sign-up for Phabricator as pointed out on the previous mail and
> submit the patch there https://llvm.org/docs/Phabricator.html
> 
> > Still not sure why github PR's can't be accepted to remove all this
> > friction for outside developpers.
> >
> 
> Because llvm main repo is still on svn. Once the migration to GitHub will
> happen, probably PR will be accepted at some point.
> 
> Thanks,
> 
> --
> Davide
> ___
> 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] Command history line editing

2018-03-07 Thread Ted Woodward via lldb-dev
There is - editline.

 

http://thrysoee.dk/editline/

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: William Schmidt [mailto:t.william.schm...@gmail.com] 
Sent: Wednesday, March 07, 2018 1:34 PM
To: paul.robin...@sony.com
Cc: ted.woodw...@codeaurora.org; jan.kratoch...@redhat.com; 
lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Command history line editing

 

readline has been around for donkeys' years. I was hacking it in MKSToolkit 
back in the nineties. That implementation had a bug that hosed the debugger's 
command line and a shell work-around to resolve it. Presumably, there must be a 
clean-room version of readline somewhere that does not use GPL? bash owns the 
command line so applications should mimic its behavior, or at least offer a 
user-selectable option. Say, either emacs or vi editing modes, as bash itself 
does.

 

Will








 

On Wed, Mar 7, 2018 at 11:53 AM, <paul.robin...@sony.com 
<mailto:paul.robin...@sony.com> > wrote:

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
> <mailto:lldb-dev-boun...@lists.llvm.org> ] On Behalf Of Ted
> Woodward via lldb-dev
> Sent: Wednesday, March 07, 2018 9:40 AM
> To: 'Jan Kratochvil'; 'William Schmidt'; lldb-dev@lists.llvm.org 
> <mailto:lldb-dev@lists.llvm.org> 
> Subject: Re: [lldb-dev] Command history line editing
>
> It's not just Apple that avoids GPL. Many LLVM users cannot use GPL.
> Adding GPL code to LLDB is a non-starter.

License questions need to be cleared with the LLVM Foundation.
But my non-lawyer understanding is no GPL.
--paulr

 

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


Re: [lldb-dev] Command history line editing

2018-03-07 Thread Ted Woodward via lldb-dev
It's not just Apple that avoids GPL. Many LLVM users cannot use GPL. Adding GPL 
code to LLDB is a non-starter.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jan
> Kratochvil via lldb-dev
> Sent: Wednesday, March 07, 2018 3:20 AM
> To: William Schmidt 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Command history line editing
> 
> On Sun, 04 Mar 2018 21:03:26 +0100, William Schmidt via lldb-dev wrote:
> > lldb deserves an editing mode functionally equivalent to what bash offers.
> > And since bash is open-source, it should just be a matter of grabbing
> > the bash source that implements command line editing and going from there.
> 
> It is because lldb uses libedit while bash (and gdb) use readline.
> 
> I guess it has licensing reasons as readline is GPL (not LGPL) and Apple 
> seems to
> avoid GPL the family of licenses.  IANAL but I think an alternative linking 
> with
> readline while keeping the libedit compatibility still in place would not 
> taint
> LLDB by the GPL license.  And then OSes (such as Linux or for OSX is it
> Homebrew?) already using GPL software could link LLDB with readline.
> 
> 
> Jan
> ___
> 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] Test fails with mutex lock fail?

2018-02-23 Thread Ted Woodward via lldb-dev
Has anyone seen anything like this?

RESULT: PASSED (1 passes, 0 failures, 0 errors, 0 skipped, 0 expected
failures, 0 unexpected successes)
terminating with uncaught exception of type std::__1::system_error: mutex
lock failed: Invalid argument
[TestDataFormatterVarScriptFormatting.py FAILED]

It shows up occasionally on our buildbot runs, on different tests. I've
never seen it when running locally.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] problem with TestLoadUnload.py

2018-02-23 Thread Ted Woodward via lldb-dev
I tried to put @skipIf(...) before setUp, but it didn't work. Currently I
have the build inside an if, checking for Hexagon. We don't support this use
of shared libraries, so all tests are skipped.

I certainly don't want to build the testcase 6 times, given that we're
moving away from that! But we need some general way to skip the build for
systems that can't build a given testcase. I have many tests skipped when
running without an OS, because we don't support c++11 in that mode.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: apra...@apple.com [mailto:apra...@apple.com]
> Sent: Friday, February 23, 2018 2:47 PM
> To: Ted Woodward 
> Cc: Pavel Labath 
> Subject: Re: problem with TestLoadUnload.py
> 
> 
> 
> > On Feb 23, 2018, at 12:08 PM, Ted Woodward
>  wrote:
> >
> > Hi Adrian,
> >
> > In r324368 you changed TestLoadUnload.py to do a build in the setUp
> > function. This seems to be called before the actual testcases are
> > checked, so a skipped testcase would still call setUp and do the
> > build. If the build fails (say, on systems that don't have libgen.h),
> > the test errors out before it can be skipped.
> >
> > Would you mind moving the build into each testcase?
> 
> +Pavel
> 
> I'm afraid that would cause quite a performance degradation in the case
where
> the test is not skipped wince we then need to build the test once for each
test
> function. On the other hand since Pavel's change to run each test function
in
> parallel we are presumably building the test once per test function
anyway, so
> this should not be any more expensive.
> 
> That said, I wonder if the right solution for your problem wouldn't be to
not run
> setUp if the test depending on it is skipped.
> 
> (Do you mind if I add lldb-dev to the CC list?)
> 
> -- adrian
> 
> > Thanks,
> >
> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >


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


[lldb-dev] display register fields?

2018-01-29 Thread Ted Woodward via lldb-dev
Is there a way to define and display register fields, like gdb? Or would
this need to be done in python?

Example:
(gdb) p/x $vac0
$3 = {value = 0xedcba111, fields = {LENGTH = 0x111, SRC4_BANK = 0xa,
SRC3_BANK = 0xb,
  SRC2_BANK = 0xc, SRC1_BANK = 0xd, DEST1_BANK = 0xe}}


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

2018-01-17 Thread Ted Woodward via lldb-dev
I disagree that understanding CMake is required to build LLVM. When I build 
top-of-tree on Linux (as opposed to a build that is Hexagon only) I make a 
build directory at the same level as my checkout, and simply run “cmake 
../llvm”. I don’t need to know anything.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Wednesday, January 17, 2018 4:31 PM
To: Adrian Prantl 
Cc: LLDB 
Subject: Re: [lldb-dev] Questions about the LLDB testsuite and improving its 
reliability

 

I don't think new test authors really need to add CMake any more so than they 
currently need to understand Make.  Which is to say, not very much.  Most 
Makefiles are currently 1-2 lines of code that simply does nothing other than 
include the common Makefile.

 

On the other hand, CMake defines a lot of constructs designed to support 
portable builds, so actually writing and maintaining that common CMake build 
file would be much easier.  The existing Makefile-based system already doesn't 
require you to understand the specific compiler invocations you want.  Here's 3 
random Makefiles, which is hopefully representative given that I pulled them 
completely at random.

 

breakpoint-commands/Makefile:

LEVEL = ../../../make

CXX_SOURCES := nested.cpp

include $(LEVEL)/Makefile.rules

 

functionalities/inferior-assert:

LEVEL = ../../make

C_SOURCES := main.c

include $(LEVEL)/Makefile.rules

 

 

types:

LEVEL = ../make

# Example:

#

# CXX_SOURCES := int.cpp

include $(LEVEL)/Makefile.rules

 

None of this is particularly interesting.  There are a very few tests that need 
to do something weird.  I opened 10 other random Makefiles and still didn't 
find any.  I don't believe it would be hard to support those cases.

 

So now instead of "understand Make" it becomes "understand CMake".  Whic is 
already a requirement of building LLVM.

 

If our test suite was lit-based where you actually had to write compiler 
invocations into the test files, I would feel differently, but that isn't what 
we have today.  We have something that is almost a direct mapping to using 
CMake.

 

On Wed, Jan 17, 2018 at 2:22 PM Adrian Prantl  > wrote:



> On Jan 17, 2018, at 1:45 PM, Vedant Kumar   > wrote:
>
> I would prefer having all of our test dependencies tracked by CMake for all 
> the reasons Zach brought up, but I think we should defer that undertaking 
> until after the bots are more stable. We have some immediate problems caused 
> by stale in-tree test artifacts. As a first milestone, it'd be great to not 
> have to run `git clean -fdx` anymore.

I'm pretty sure I do not want to go all the way to CMake right now, but I am 
curious about your motivation: Why do you think that using CMake to build the 
tests in the testsuite is a good idea? In my opinion this adds a layer of 
complexity to the tests that makes it harder to understand what exactly is 
happening and test authors now need to understand CMake *and* the compiler 
invocations they want to execute in their tests. Do you also share Zachary's 
point of view that the tests should be build artifacts that should be kept 
after an incremental build?

-- adrian

>
>
>> On Jan 17, 2018, at 1:13 PM, Davide Italiano via lldb-dev 
>>  > wrote:
>>
>> On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano >  > wrote:
>>> On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev
>>>  > wrote:
 Hi lldb-dev!

 I've been investigating some spurious LLDB test suite failures on 
 http://green.lab.llvm.org/green/ that had to do with build artifacts from 
 previous runs lying around in the test directories and this prompted me to 
 ask a couple of general noob questions about the LLDB testsuite.

 My understanding is that all execution tests are compiled using using 
 `make` in-tree. I.e.: the test driver (dotest.py) effectively executes 
 something equivalent to `cd $srcdir/packages/.../mytest && make`. And it 
 does this in a serial fashion for all configurations (dwarf, dSYM, dwo, 
 ...) and relies on the `clean` target to be implemented correctly.

 I don't understand all the design decisions that went into the LLDB 
 testsuite, but my naive intuition tells me that this is sub-optimal 
 (because of the serialization of the configurations) and dangerous 
 (because it relies on make clean being implemented correctly). It seems to 
 me that a better approach would be to create a separate build directory 
 for each test variant 

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-20 Thread Ted Woodward via lldb-dev


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Wednesday, December 20, 2017 12:41 PM
> To: Pavel Labath 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of
> type names inequality in DWARF and mangled symbols
> 
> 
> Modifying llvm-dsymutil to handle ELF so we can use "llvm-dsymutil --update
> foo.elf" is the quickest way that doesn't involve modifying anything but llvm-
> dsymutil. It will generate the accelerator tables manually and add/modify the
> existing accelerator tables and write out the new elf file that is all fixed 
> up. I
> would suggest going this route at first to see what performance improvements
> we will see with linux so that can drive how quickly we need to adopt this.

I like this. The question is - has everything we need in llvm-dsymutil been 
upstreamed by Apple?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

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


Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu

2017-11-27 Thread Ted Woodward via lldb-dev
I ran into the same problem with lldb 3.8 on Ubuntu 14.04. I created symlinks 
to get things working right. Now I can run "lldb" and it finds lldb-server.

In /usr/bin:
0 lrwxrwxrwx 1 root root 26 Nov 17 15:22 /usr/bin/lldb -> 
/usr/lib/llvm-3.8/bin/lldb*
0 lrwxrwxrwx 1 root root 24 Jul 18 11:06 /usr/bin/lldb-3.8 -> 
../lib/llvm-3.8/bin/lldb*
0 lrwxrwxrwx 1 root root 30 Jul 18 11:06 /usr/bin/lldb-3.8.0-3.8 -> 
../lib/llvm-3.8/bin/lldb-3.8.0*
0 lrwxrwxrwx 1 root root 24 Aug 23 17:50 /usr/bin/lldb-server -> 
/usr/bin/lldb-server-3.8*
0 lrwxrwxrwx 1 root root 31 Jul 18 11:06 /usr/bin/lldb-server-3.8 -> 
../lib/llvm-3.8/bin/lldb-server*

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> Labath via lldb-dev
> Sent: Monday, November 27, 2017 5:32 AM
> To: Jeremiah 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu
> 
> I think that's a question for your distro's (or ubuntu's) lldb package 
> maintainer. I
> think they probably have some custom patches there (if they don't then they
> probably need them). If I'm not mistaken vanilla lldb does not even support
> multiple lldb instalations side-by-side (i.e., it will always search for 
> "lldb-
> server", with no suffix).
> 
> As a workaround, you may be able to get this working by setting the
> LLDB_DEBUGSERVER_PATH environment variable to point to the right
> executable.
> 
> On 26 November 2017 at 06:04, Jeremiah via lldb-dev  d...@lists.llvm.org> wrote:
> > On my Pop!_OS machine (which is based on Ubuntu 17.10), using any
> > version of LLDB above 3.8 gives me the error "process launch failed:
> > unable to locate lldb-server-x.x.x" but when version 3.8 is installed,
> > it works just fine.
> >
> > There are various posts across the web about the same problem on
> > multipler versions of Ubuntu. The most common solution presented is to
> > use update-alternatives, but that did not solve the problem for me. I
> > also checked my bin directories and the binaries for lldb-server are
> > there for any version I install.
> > ___
> > 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


[lldb-dev] SB Headers not in install?

2017-11-10 Thread Ted Woodward via lldb-dev
In r309021, the headers in include/lldb/API were excluded from the install
target. From cmake/modules/LLDBConfig.cmake:

+ PATTERN "API/*.h" EXCLUDE


Are the SB Headers supposed to be excluded from an install? I just did
"ninja install" from top of tree and the SB Headers are not there.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Ted Woodward via lldb-dev
We had the same problem internally on our bots. A clean build blew away the 
cmake caches and fixed the problem.

 

Ted

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Don Hinton 
via lldb-dev
Sent: Tuesday, November 07, 2017 12:28 PM
To: Jim Ingham 
Cc: LLDB 
Subject: Re: [lldb-dev] Bot failure with new "in tree compiler" changes 
(r316728) in llvm.org bot

 

I hit the same problem last week.  I ended up blowing away my build directory, 
and the problem went away.  

 

Probably a cache issue, but I was unable to reproduce...

 

On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev 
 > wrote:

The lldb_cmake GreenDragon bot is now failing, e.g.:

http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e

This looks related to Pavel's change:

> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
>
> Default to using in-tree clang for building test executables
>
> Summary:
> Using the in-tree clang should be the default test configuration as that
> is the one compiler that we can be sure everyone has (better
> reproducibility of test results). Also, it should hopefully reduce the
> impact of pr35040.
>
> This also reduces the number of settings which control the compiler
> used. LLDB_TEST_C_COMPILER is used for C files and
> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> the in-tree clang.
>
> Reviewers: zturner
>
> Subscribers: mgorny, davide, lldb-commits
>
> Differential Revision: https://reviews.llvm.org/D39215
>

The error is:

CMake Error at tools/lldb/CMakeLists.txt:78 (message):

  LLDB test compilers not specified.  Tests will not run


Does the bot need to be reconfigured for these changes?

Jim

___
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] check-lldb will start using in-tree clang by default

2017-10-27 Thread Ted Woodward via lldb-dev
I think if clang exists in-tree, it should be used. If it doesn't, the compiler 
used to build lldb should be used.

Unless, of course, the compiler is specified with the cmake variables.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide
> Italiano via lldb-dev
> Sent: Friday, October 27, 2017 2:46 PM
> To: Pavel Labath 
> Cc: LLDB 
> Subject: Re: [lldb-dev] check-lldb will start using in-tree clang by default
> 
> So, I wiped out my directory for the build and then I created it again using
> cmake -GNinja ../
> 
> I found out what the bug/problem is, BTW (was going to reply to this e-mail 
> but
> you've beaten me to the punch).
> You switched LLDB to build with an in-tree clang, but ninja check-lldb doesn't
> really require clang to be built.
> As such, once I cleaned up my checkout, I ended up typing just `ninja 
> check-lldb`
> and that failed because clang wasn't built.
> I claim that `ninja check-lldb` should list clang as dependency when we're
> running the tests with the in-tree clang.
> WDYT?
> 
> Thanks!
> 
> --
> Davide
> 
> 
> 
> On Fri, Oct 27, 2017 at 12:41 PM, Pavel Labath  wrote:
> > Did you clean your cmake cache before runinng this? Does
> > '/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
> > binary you just built?
> >
> > On 27 October 2017 at 12:39, Davide Italiano 
> wrote:
> >> Yes, it seems `configuration.compiler` is None, so this explodes:
> >>
> >> [...]
> >> if not is_exe(configuration.compiler):
> >>
> >> [...]
> >>
> >> On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano 
> wrote:
> >>> I think that this change (or some change nearby) broke `check-lldb` on
> Fedora.
> >>>
> >>> I'm investigating, but in the meanwhile, here's the log.
> >>>
> >>> $ ninja check-lldb
> >>> [2/2] Testing LLDB (parallel execution, with a separate subprocess
> >>> per test) Traceback (most recent call last):
> >>>   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
> >>> 7, in 
> >>> lldbsuite.test.run_suite()
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py",
> >>> line 1099, in run_suite
> >>> parseOptionsAndInitTestdirs()
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py", line 282, in parseOptionsAndInitTestdirs
> >>> if not is_exe(configuration.compiler):
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py",
> >>> line 54, in is_exe
> >>> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
> >>>   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
> >>> st = os.stat(path)
> >>> TypeError: coercing to Unicode: need string or buffer, NoneType
> >>> found
> >>> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
> >>> /usr/bin/python2.7
> >>> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q
> >>> --arch=x86_64 --executable /home/davide/work/build-lldb/bin/lldb -s
> >>> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
> >>> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
> >>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
> >>> ninja: build stopped: subcommand failed.
> >>>
> >>> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
> >>>  wrote:
>  I am going to check in a change (D39215) which causes the
>  check-lldb target to use the just-built clang for compiling the
>  test inferiors (instead of the system compiler, which was the old
>  default). The main reason for this is to provide better
>  reproducibility of test results between different
>  machines/developers, by removing one of the main sources of
>  nondeterminism. This behavior can be overridden by setting the
> LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
> 
>  For the change to take effect you will need to clean your build
>  folder (or at least, remove the affected variables from your
> CMakeCache.txt).
>  After this you may observe a change in the test results from the
>  check-lldb run.
> 
>  Note that this change only affect cmake code -- if you run your
>  tests by running dotest.py directly, nothing will change for you.
> 
>  regards,
>  pavel
>  ___
>  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] warnings in source/Plugins/Language/ObjC/NSArray.cpp

2017-08-29 Thread Ted Woodward via lldb-dev
r310959 contains GNU extensions in source/Plugins/Language/ObjC/NSArray.cpp.
Building with clang 3.8 and -WError, I see:

/local/mnt/workspace/bots/llvmhexbot-sles11_sd_48/hexagon-clang-83/build/llv
m/tools/lldb/source/Plugins/Language/ObjC/NSArray.cpp:181:7: error:
anonymous structs are a GNU extension [-Werror,-Wgnu-anonymous-struct]
  struct {
  ^
/local/mnt/workspace/bots/llvmhexbot-sles11_sd_48/hexagon-clang-83/build/llv
m/tools/lldb/source/Plugins/Language/ObjC/NSArray.cpp:181:7: error:
anonymous types declared in an anonymous union are an extension
[-Werror,-Wnested-anon-types]


The patch is to handle new MacOS 10.13 internal layouts. Could someone at
Apple please clean this up?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Linking the lldb C++API/library with other projects

2017-08-29 Thread Ted Woodward via lldb-dev
 

lldb-mi, in /tools/lldb-mi , loads the shared library and uses the SB 
APIs. That might be a good start for you. main() is in MIDriverMain.cpp.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of meister 
via lldb-dev
Sent: Tuesday, August 29, 2017 1:41 PM
To: clayb...@gmail.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Linking the lldb C++API/library with other projects

 

Greg,

 

We are developing a compiler for Common Lisp that uses LLVM as the backend and 
interoperates with C++ - it has its own REPL and built in compiler.   

Our compiler generates llvm-ir that we link directly with llvm-ir generated 
from the C++ code using LTO.

I’ve exposed much of the LLVM C++ API and Clang ASTMatcher C++ API for 
automatic analysis and refactoring of our C++ code.

 

The Python API’s are not that useful to us.   

Although - maybe launching lldb as a separate process to get the backtrace with 
a python script may be a reasonable thing to do - if that’s all that I want to 
do.

I’d also like to explore accessing lexical variables and setting breakpoints 
and watchpoints using the C++ API.

The C++ API’s - they are much more straightforward to work with for us.

 

I am already using ‘backtrace’ - but I don’t get function arguments with that 
sadly.

 

Best,

 

.Chris.

 

 

 

 

On Aug 29, 2017, at 2:30 PM, Greg Clayton  > wrote:

 

 

On Aug 29, 2017, at 11:17 AM, meister  > wrote:

 

Dear Greg,

Thank you very much for your detailed and thoughtful response.

A couple of followup questions based on what you said:

(1)  You say: "since LLDB can't be used to backtrace itself…"
Do I (a) need to fork another process and call the LLDB API’s to get backtraces 
for the original process or (b) can I simply create another thread and call 
LLDB API’s to interogate other threads using the SBThread API?  Or can I do 
both of these?

 

You can do the first, not the second. LLDB attaches to processes via ptrace 
which means it will suspend all threads in the process it is attaching to, so 
you can't do this to yourself. Forking another process will do the trick. You 
can also do all of this from Python! The entire LLDB API is exposed to python 
and python can be used on the command line from a python script, or from within 
LLDB itself by using the "script" command which drops you into an embedded 
python interpreter.  On Mac, if you know Xcode is installed, you can just run a 
python script to do what you need. Let me know if this sounds interesting. On 
linux, you could use the installed lldb to do the backtraces using a python 
script as well.






(2) When you say "so if you are looking to backtrace things in your current 
process you should probably use other APIs.”
By "other APIs” do you mean other SB class API’s like SBThread? or do you 
mean other API’s entirely? If the latter could you give an example?

 

Other APIs not in LLDB if you must stay in process:

 

$ man backtrace

 

If you launch another process, it will be able to backtrace your current 
process and you can use LLDB's APIs.

 


(3) If I call LLDB from my code like this - how would you recommend 
distributing this?

(a) When building from source should I have the build system pull lldb from a 
the llvm github repo?

 

You might think about locking onto they latest public release of lldb. This 
might be more stable than just grabbing top of tree.





(b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my binary 
release?

 

Yes. You might think about using python and just using the installed LLDB? 





(c) On OS X - can I use the builtin lldb library? I haven’t checked if header 
files are available.

 

Header files are not available, but our API is stable. You could theoretically 
link against the top of tree LLDB.framework and tell it to use the system 
version (in /Applications/Xcode.app/Contents/SharedFrameworks, or somewhere for 
linux)





(d) On Linux - can I use package manager installed versions of lldb? 

 

Yes. If you go this route, I would suggest using a python script. Then you 
don't even need to link against lldb! 






For some of these I realize that I'll have to do some legwork to figure out 
what is available from package managers etc.

(4) Since I have to debug from a separate process does the following sound 
reasonable.
(i) My program detects an error and enters into its debugger.
(ii) It forks a debugging process and that interacts with the user who uses it 
to debug the main process.
(iii) The debugger process shuts down and the main process continues.

I’d be doing this from within a Common Lisp programming environment called 
SLIME in Emacs - I have no idea right now if it’s possible to have the 

[lldb-dev] hang bug in lldb-mi -var-update

2017-08-25 Thread Ted Woodward via lldb-dev
I found a hang in lldb-mi's -var-update. It checks to see if a var changed,
then it checks each of the children recursively. If a child is a pointer
back to a parent, as in this case:

struct complex_type
{
int i;
struct { long l; } inner;
struct complex_type *complex_ptr;
};

void
var_update_test(void)
{
struct complex_type complx_array[2];

complx_array[0].i = 4;
complx_array[0].inner.l = 4;
complx_array[0].complex_ptr = _array[1];
complx_array[1].i = 5;
complx_array[1].inner.l = 5;
complx_array[1].complex_ptr = _array[0];
 


the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
infinite loop.

  const MIuint nChildren = vrwValue.GetNumChildren();
  for (MIuint i = 0; i < nChildren; ++i) {
lldb::SBValue member = vrwValue.GetChildAtIndex(i);
if (!member.IsValid())
  continue;

if (member.GetValueDidChange()) {
  vrwbChanged = true;
  return MIstatus::success;
} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
  // Handle composite types (i.e. struct or arrays)
  return MIstatus::success;
  }

I've got a patch that disables checking a pointer's children. I'll put it up
on phabricator today.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Remote debugging ARM target from x86 host

2017-08-24 Thread Ted Woodward via lldb-dev
The lldb-server launch line looks ok; it should take the port 0 arg and get a 
port from the OS. 
lldb is getting the port back from lldb-server in 4.0.1, as seen here:

> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543 
> port

But for 5.0.0 we see it fail the debugserver launch, and get:

> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port

That log message comes right after the pipe read, which succeeds because 
error.Success() is true:

// Read port from pipe with 10 second timeout.
error = socket_pipe.ReadWithTimeout(
port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
if (error.Success() && (port != nullptr)) {
  assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
  uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
  if (*port == 0 || *port == child_port) {
*port = child_port;
if (log)
  log->Printf("GDBRemoteCommunication::%s() "
  "debugserver listens %u port",
  __FUNCTION__, *port);

As an aside, I don't like that assert - if we get garbage back from the pipe, 
we should error out, not take down lldb.

Another aside, the definition of port_cstr is odd:
char port_cstr[PATH_MAX] = {0};
port_cstr[0] = '\0';
The size is way to big - max port number is 65535, so we don't need PATH_MAX 
bytes. And 2 assignments to make it a null string?


Ramana, can you stick in a log message to print port_cstr? I suspect it's 
actually getting 0 back from lldb-server, which would tell us the error is in 
the server code, not the client code.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Ramana [mailto:ramana.venka...@gmail.com]
> Sent: Thursday, August 24, 2017 4:00 AM
> To: Ted Woodward 
> Cc: Greg Clayton ; Hans Wennborg
> ; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Greg, Ted
> 
> Thanks for your comments.
> 
> On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward
>  wrote:
> >
> > What should be happening is Handle_qLaunchGDBServer calls
> LaunchGDBServer with a port of UINT16_MAX, which tells it to use a port in its
> port list. It shouldn't have a port list, so should return 0. LaunchGDBServer 
> calls
> StartDebugServerProcess with a port of 0 in the url. StartDebugServerProcess
> launches the gdbserver with a named pipe, and reads the actual port from the
> pipe.
> 
> Yes, the port list is empty unless --(min/max)-gdbserver-port is specified and
> the gdbserver reads port number from the named pipe which in the failing case
> is zero.
> 
> > I suggest turning on more logging - specifically, "gdb-remote process". 
> > That's
> the channel used in StartDebugServerProcess.
> >
> 
> In fact I have given the relevant log line of "gdb-remote process" in the bug
> details reporting port zero. Anyhow, the full log of "gdb-remote process" for
> both lldb v4.0.1 and v5.0.0 is given at the bottom of my reply.
> 
> I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits for 
> child
> debug servers to start up when passing them) got something to do with this bug
> but both reversing
> 
> if (pass_comm_fd == -1) {   at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086
> 
> to original
> 
>if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port ==
> nullptr)) {
> 
> and
> 
> increasing the time out to 30 sec from 10 sec in
> socket_pipe.ReadWithTimeout()at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255
> 
> did not solve the issue.
> 
> By the way, the remote debugging of x86 (linux) from x86 (linux) with lldb
> v5.0.0 (but works with v4.0.1) also fails with assertion
> 
> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');  at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1258
> 
> due to the reason that socket_pipe.ReadWithTimeout() could not successfully
> read the port number from the named pipe.
> 
> Based on the above, though I am not sure, the other patch I could think of
> having an effect on this bug is
> https://reviews.llvm.org/rL300579 (Update LLDB Host to support IPv6 over TCP)
> which changed the socket implementation.
> 
> 
> lldb-server log for "gdb-remote process" with lldb v4.0.1 (passing case)
> 
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0,
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote stub
> exe '/mnt/var/binaries/arm_release/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server"
> argv[1]="gdbserver"
> 

Re: [lldb-dev] Remote debugging ARM target from x86 host

2017-08-23 Thread Ted Woodward via lldb-dev

What should be happening is Handle_qLaunchGDBServer calls LaunchGDBServer with 
a port of UINT16_MAX, which tells it to use a port in its port list. It 
shouldn't have a port list, so should return 0. LaunchGDBServer calls 
StartDebugServerProcess with a port of 0 in the url. StartDebugServerProcess 
launches the gdbserver with a named pipe, and reads the actual port from the 
pipe.

I suggest turning on more logging - specifically, "gdb-remote process". That's 
the channel used in StartDebugServerProcess.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Wednesday, August 23, 2017 12:45 PM
> To: Hans Wennborg 
> Cc: Ramana ; LLDB Dev  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Port zero should never be returned as a valid port. We do bind to port zero 
> just
> so we don't try and pick a port at random just to find it is being used. When 
> we
> bind to port 9, we must find the actual port we bound to and return that. 
> Seems
> something has gone wrong with the code that discovers the port that was
> actually bound and is not reporting that back correctly.
> 
> 
> Should be straight forward to do by debugging the function
> GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) in
> GDBRemoteCommunicationServerPlatform.cpp and see what is going on and
> why it is returning 0 as the port.
> 
> Greg
> 
> > On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > This was marked as an lldb 5.0.0 release blocker since it's a
> > regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183
> >
> > lldb-dev: Is there any interest in fixing this bug?
> >
> > On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
> >  wrote:
> >> Hi,
> >>
> >> I am trying to remote debug ARM (linux) target from x86 (linux) host
> >> and I am getting the following error while trying to launch a process.
> >> The local debugging on ARM works.
> >>
> >> error: connect remote failed (invalid host:port specification:
> >> '10.10.2.3')
> >> error: process launch failed: invalid host:port specification: '10.10.2.3'
> >>
> >> It appears the above error is because the gdb-remote is returning the
> >> communication port as zero.
> >>
> >> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
> >> <  19> read packet: $pid:298;port:0;#bf
> >>
> >> What are the possible reasons for the above behavior from gdb-remote
> >> and how I could resolve this?
> >>
> >> If it helps, below is the full log.
> >>
> >> (lldb) log enable lldb comm
> >> (lldb) log enable gdb-remote packets
> >> (lldb) platform select remote-linux
> >>  Platform: remote-linux
> >> Connected: no
> >> (lldb) platform connect connect://10.10.2.3:500
> >> 0x915bd78 Communication::Communication (name = gdb-remote.client)
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
> >> Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect
> >> (host/port = 10.10.2.3:500)
> >> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
> >> us, connection = 0x0915F578
> >> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
> >> flags = 0) => 19 (error = (null))
> >> history[1] tid=0x7cbf <   1> send packet: +
> >> <  19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst =
> >> 0xBFCB51AC, dst_len = 8192, timeout = 600 us, connection =
> >> 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
> >> flags = 0) => 7 (error = (null))
> >> <   1> read packet: +
> >> <   6> read packet: $OK#9a
> >> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
> >> flags = 0) => 13 (error = (null)) <  13> send packet: $qHostInfo#9b
> >> this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout =
> >> 100 us, connection = 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len =
> >> 316, flags = 0) => 316 (error = 

Re: [lldb-dev] Forcing lldb to refresh process state

2017-08-23 Thread Ted Woodward via lldb-dev
Perhaps a manual packet that tells your remote server that the next "s"
packet is a reverse step, then run the lldb command "si".

 

It would be simpler, from a packet log analysis standpoint, if you weren't
stopped at a breakpoint location when you did this.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
Clayton via lldb-dev
Sent: Tuesday, August 22, 2017 6:20 PM
To: Vadim Chugunov 
Cc: LLDB 
Subject: Re: [lldb-dev] Forcing lldb to refresh process state

 

You need to send some sort of continue through the GDB remote interface. The
only way to get a $T packet back is in response to a "?" packet or to a
"vCont" or other continue or step packet.

 

On Aug 22, 2017, at 2:30 PM, Vadim Chugunov  > wrote:

 

It does send '$T05...' in response, but it looks like lldb does not analyze
responses to manually sent packets.

 

On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton  > wrote:

If you do a reverse step it actually should send a process resumed and a
process stopped event.

> On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev  > wrote:
>
> I'm trying to reverse-step.  So I think I'd need to refresh all thread
states?
>
>> On Aug 18, 2017, at 4:50 PM, Jim Ingham  > wrote:
>>
>> No, there hasn't been a need for this.
>>
>> What commands are you planning to send?  Or equivalently, how much state
are you expecting to change?
>>
>> Jim
>>
>>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev
 > wrote:
>>>
>>> Hi,
>>> Is there any way to force lldb to refresh it's internal record of
debuggee process state (as if it had just received a stop event)?  I want to
send a custom command to remote gdb process stub (via `process plugin packet
send`).  This works, but if the command alters debuggee state, lldb won't
know about it.
>>> ___
>>> 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] Emacs LLDB support & the GDB/MI Interface

2017-07-31 Thread Ted Woodward via lldb-dev
The original lldb-mi implementation was to get Eclipse talking to lldb. Since 
then there have been other people working on it, and other clients, but lldb-mi 
is not a full implementation of the MI protocol.

The best thing to do is give us a list of commands that are failing, in a bug 
opened in Bugzilla at http://bugs.llvm.org .

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hafiz
> Abid Qadeer via lldb-dev
> Sent: Monday, July 31, 2017 5:04 AM
> To: Eli Zaretskii ; Zachary Turner ; Jan
> Kratochvil ; Eli Zaretskii via lldb-dev  d...@lists.llvm.org>
> Cc: yllumin...@gmail.com
> Subject: Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
> 
> 
> >>> Last time I tried, it wasn't "reasonable" enough to start debugging
> >> a
> >>> program under Emacs.  See this discussion for details:
> >>>
> >>> http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html
> >>>
> >>> The failed commands it shows are the initial ones issued by Emacs
> >>> when a debugging session starts.  Without support of these commands
> >> in
> >>> lldb-mi there's no hope for any
> >>> practical debugging using lldb.
> >>> If llvm developers could implement those minimal commands, maybe
> the
> >>> rest would be easier.
> 
> I will try to add those command when my time allows. If there are others that
> are needed to make Emacs work then please let me know or better open a
> bug.
> 
> Thanks,
> Abid
> 
> --
> Hafiz Abid Qadeer
> Mentor Embedded/CodeSourcery
> ___
> 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] Trying to use socketpair for lldb-server fails

2017-07-24 Thread Ted Woodward via lldb-dev
This is big time overkill, but I wasn’t sure where the problem I was tracking 
down was:

 

“lldb all:linux all:gdb-remote all”

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Demi Obenour [mailto:demioben...@gmail.com] 
Sent: Friday, July 21, 2017 8:54 PM
To: Ted Woodward ; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Trying to use socketpair for lldb-server fails

 

Sadly, that gives me nothing in the log file.  Also, 
ConnectionFileDescriptor::Connect already seems to handle this case.

 

Running strace on all child processes gives a “Operation not permitted” error 
from setsid().  That seems like the culprit, which is strange.

 

Would you mind providing the value you used for LLDB_SERVER_LOG_CHANNELS?

 

Demi

 

On Fri, Jul 21, 2017 at 2:55 PM Ted Woodward  > wrote:

The first thing I'd do is use the lldb logging mechanism. lldb-server closes
its own stdout and stderr, because nobody is interested in output from the
server, just from the target. Except when you're debugging the server, so
there is an easy way to turn on logging.

Set the following environment variables:
LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will
be written to
LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn
logging on for. The format is "channel category:channel category...". If you
want more than 1 category for a channel, I think "channel cat1 cat2..."
works. This is not spelled out very clearly, unfortunately.


Quickly glancing at the code, it looks like you need to implement a
socketpair connection, and handling of the fd:// connection URL, starting in
ConnectionFileDescriptor::Connect. The log for this would be "lldb
connection".

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
>  ] On Behalf Of Demi
> Obenour via lldb-dev
> Sent: Wednesday, July 19, 2017 7:44 PM
> To: lldb-dev@lists.llvm.org  
> Subject: [lldb-dev] Trying to use socketpair for lldb-server fails
>
> To avoid a local privilage escalation, I am trying to patch LLDB not to
use a TCP
> socket for local communication.
>
> The attached patch failed.  Would anyone be able to provide suggestions
for
> how to debug the problem?
>
> Sincerely,
>
> Demi

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


Re: [lldb-dev] Trying to use socketpair for lldb-server fails

2017-07-21 Thread Ted Woodward via lldb-dev
The first thing I'd do is use the lldb logging mechanism. lldb-server closes
its own stdout and stderr, because nobody is interested in output from the
server, just from the target. Except when you're debugging the server, so
there is an easy way to turn on logging.

Set the following environment variables:
LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will
be written to
LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn
logging on for. The format is "channel category:channel category...". If you
want more than 1 category for a channel, I think "channel cat1 cat2..."
works. This is not spelled out very clearly, unfortunately.


Quickly glancing at the code, it looks like you need to implement a
socketpair connection, and handling of the fd:// connection URL, starting in
ConnectionFileDescriptor::Connect. The log for this would be "lldb
connection".

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Demi
> Obenour via lldb-dev
> Sent: Wednesday, July 19, 2017 7:44 PM
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] Trying to use socketpair for lldb-server fails
> 
> To avoid a local privilage escalation, I am trying to patch LLDB not to
use a TCP
> socket for local communication.
> 
> The attached patch failed.  Would anyone be able to provide suggestions
for
> how to debug the problem?
> 
> Sincerely,
> 
> Demi

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


Re: [lldb-dev] Python scripting in Windows LLDB

2017-06-30 Thread Ted Woodward via lldb-dev
I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 
.so/library directory, so I’m not willing to say building on Windows with 3.6.1 
and using the 3.5.2 dll/library directory will work. Python has never been very 
forgiving when using a different setup than what you built with.

 

My point with that statement is you’ve got to make sure the runtime environment 
matches the build environment, something harder to do on Windows where there is 
no default runtime environment.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Friday, June 30, 2017 3:05 PM
To: Ted Woodward <ted.woodw...@codeaurora.org>; Jamie Madill 
<nul...@gmail.com>; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Python scripting in Windows LLDB

 

 

On Fri, Jun 30, 2017 at 12:39 PM Ted Woodward via lldb-dev 
<lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote:

Python support on Windows is much more problematic than support on something 
like MacOS or Linux. The python you use when you run lldb must be the same 
python used when you build it. Bad things happen – warnings, crashes, etc – 
when you use a different rev of the dll/so or the library directory (which 
contains dlls/sos) than what was used when building lldb. 

This is no longer true right?  That was one of the major drivers behind moving 
to Python 3.5.  All that matters is 

 

a) The build configuration matches (if LLDB was built against Python debug, you 
must have debug libraries available)

b) The architecture matches (if it's an x64 build of LLDB, you need x64 Python 
libraries)

c) The version is 3.5 or higher.

 

Aside from that it shouldn't matter

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


Re: [lldb-dev] Python scripting in Windows LLDB

2017-06-30 Thread Ted Woodward via lldb-dev
Python support on Windows is much more problematic than support on something 
like MacOS or Linux. The python you use when you run lldb must be the same 
python used when you build it. Bad things happen – warnings, crashes, etc – 
when you use a different rev of the dll/so or the library directory (which 
contains dlls/sos) than what was used when building lldb. MacOS and various 
Linux distros ship with a fixed version of python, so lldb can be built with 
that version. Windows doesn’t have a default python, so you need to make sure 
that your user has the same version of python that lldb was built with.

 

For the Hexagon tools, we ship the python dll/so and the library directory that 
we built with. We use 3.5.1 on Windows, and 2.7.8 on Linux. On Linux, we set 
RPATH to ../lib, so lldb/liblldb.so can find libpython.so. On both, we set a 
cmake variable LLDB_DEFAULT_PYTHONHOME, and use it when initializing python to 
point lldb to the path where our python library is installed. This code isn’t 
upstreamed, but I can upstream it if the community would like it.

 

Another issue on Windows is the python installation integrity check in 
cmake/modules/LLDBConfig.cmake. It checks to see if python is installed 
correctly like this:

if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND 
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))

message("Python installation is corrupt. Python support will be disabled 
for this build.")

set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

return()

  endif()

 

 

If you don’t have the debug version of python installed (as is the case on our 
builders), this check will fail, and python will be turned off. Internally, I 
break this check up into debug and release checks, based on the value of 
CMAKE_BUILD_TYPE. I also don’t check for the release dll, because our builders 
don’t have that.  I can also upstream this if the community is interested.

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jamie 
Madill via lldb-dev
Sent: Thursday, June 29, 2017 10:30 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Python scripting in Windows LLDB

 

A ping for this regression - Ted Woodward seems to have had a patch for fixing 
broken Windows scripting support but the 5.0.0 snapshot release didn't have the 
fix. Is it possible to land that patch for the next snapshot?

 

This is currently breaking LLDB Visual Studio Code integration on Windows (for 
context, see https://github.com/vadimcn/vscode-lldb/issues/37 .)

 

Thanks!

Jamie

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


Re: [lldb-dev] Support for Error Strings in remote protocol

2017-06-21 Thread Ted Woodward via lldb-dev
What we can't do is require the remote server to support the new protocol. 
lldb-server isn't the only thing we talk to, and failing because we didn't get 
a specific non-RSP conformant error packet would be bad.

I like Pavel's idea of enabling it via a Q packet, and after being enabled it 
should always be optional.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> Labath via lldb-dev
> Sent: Wednesday, June 21, 2017 11:41 AM
> To: Ravitheja Addepally 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Support for Error Strings in remote protocol
> 
> +1 one from me. I like the idea a lot. Specific details below.
> 
> On 21 June 2017 at 16:31, Ravitheja Addepally via lldb-dev  d...@lists.llvm.org> wrote:
> > Hello all,
> >Currently the remote protocol in LLDB does not allow sending
> > Error Strings in response to remote packets, it only allows for "ENN"
> > format where N is a hex integer. In our current ongoing work, we would
> > like to have support for Sending Error Strings from lldb-server. I
> > would like to invite any opinions or suggestions in this matter ?
> >
> > A very simple proposal would be to just attach an error string maybe
> > as a Name:Value Pair ? like so ->
> >
> > EXX;"Error String"
> >  or
> > EXX;M"Error String"
> 
> I guess the decision here depends on how forward-compatible we want to
> be. If we don't anticipate adding further fields here, then the format can 
> just
> be EXX;message and no quoting is needed. If we want to add more fields in
> the future (I don't really see what could they be though), then we should
> stick to the standard semi-colon delimited list  format. So, something like:
> EXX;message:
> But then we need to decide how to encode . I guess the most
> "standard" approach would be to hex-encode it, although it will make them
> hard to read manually.
> 
> >
> > I guess removing EXX would make it incompatible with gdb-server. Also
> > adding new packets to query errors might not be desired ?
> I think we should keep the numeric codes. Sometimes it may be useful to
> programmatically switch on them, and that's hard to do with a string only. For
> compatibility's sake, I'd only send the error messages if the client 
> explicitly
> enables it via some packet.
> 
> pl
> ___
> 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] issue with lldb-mi -var-update with pointers

2017-05-31 Thread Ted Woodward via lldb-dev
Yes, please fix the first problem.

Thanks!

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: Abid, Hafiz [mailto:hafiz_a...@mentor.com]
> Sent: Wednesday, May 31, 2017 7:09 AM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] issue with lldb-mi -var-update with pointers
> 
> I see 2 problems here. CMICmdCmdVarUpdate::ExamineSBValueForChange
> seems to ignore the changes in in children for pointer and references. It
is
> easy enough to fix. The other issue is that we dont not print the changed
> child value.
> For example, with the first issue fixed, I get
> 
> -var-update 1 var0
> ^done,changelist=[{name="var0",value="0x7fffed30",in_scope="tru
> e",type_changed="false",has_more="0"}]
> 
> This problem exist for aggregate types too.
> 
> I think I can put the fix for the first problem if it will help you.
Please let me
> know.
> 
> Thanks,
> Abid
> ____
> From: lldb-dev <lldb-dev-boun...@lists.llvm.org> on behalf of Ted
> Woodward via lldb-dev <lldb-dev@lists.llvm.org>
> Sent: Tuesday, May 30, 2017 9:50 PM
> To: 'LLDB'
> Subject: [lldb-dev] issue with lldb-mi -var-update with pointers
> 
> I have a simple testcase that modifies the value pointed to by an int *.
> I've created a variable with -var-create, and then after the value has
been
> updated, check it with -var-update. -var-update returns no changes, but
the
> value has changed.
> 
> test.c:
> #include 
> 
> int main(void)
> {
>   int vec[] = {1, 2, 3, 4};
>   int foo = 0;
>   int *bar = 
>   int i = 0;
> 
>   for (i = 0; i < 4; i++)
> *bar += vec[i];
> 
>   return foo;
> }
> 
> Commands:
> -break-insert -t -f test.c:10
> -break-insert -t -f test.c:13
> -exec-run
> -var-create --thread 1 --frame 0 - * bar -var-list-children var0
-var-evaluate-
> expression var0.*bar -exec-continue
>  1 var0
> -var-evaluate-expression var0.*bar
> 
> 
> Output:
> (gdb)
> -var-create --thread 1 --frame 0 - * bar
> ^done,name="var0",numchild="1",value="0x7fffed30",type="int
> *",thread-id="1",has_more="0"
> (gdb)
> -var-list-children var0
> ^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numch
> ild="0"
> ,type="int",thread-id="1",has_more="0"}],has_more="0"
> (gdb)
> -var-evaluate-expression var0.*bar
> ^done,value="0"
> 
> ***Value is 0
> 
> (gdb)
> -exec-continue
> ^running
> (gdb)
> =thread-exited,id="1",group-id="i1"
> (gdb)
> *running,thread-id="all"
> (gdb)
> =thread-created,id="1",group-id="i1"
> (gdb)
> *stopped,reason="breakpoint-
> hit",disp="del",bkptno="2",frame={level="0",addr
> ="0x00400530",func="main",args=[],file="test.c",fullname="/local/s
> cr
>
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
> (gdb)
> -var-update 1 var0
> ^done,changelist=[]
> 
> ***No changes
> 
> (gdb)
> -var-evaluate-expression var0.*bar
> ^done,value="10"
> 
> ***Value is 10, even though we reported no changes.
> 
> The child shows an update:
> (gdb)
> -var-update 1 var0.*bar
> ^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_ch
> anged=
> "false",has_more="0"}]
> 
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> 
> ___
> 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] issue with lldb-mi -var-update with pointers

2017-05-30 Thread Ted Woodward via lldb-dev
I have a simple testcase that modifies the value pointed to by an int *.
I've created a variable with -var-create, and then after the value has been
updated, check it with -var-update. -var-update returns no changes, but the
value has changed.

test.c:
#include 

int main(void)
{
  int vec[] = {1, 2, 3, 4};
  int foo = 0;
  int *bar = 
  int i = 0;

  for (i = 0; i < 4; i++)
*bar += vec[i];

  return foo;
}

Commands:
-break-insert -t -f test.c:10
-break-insert -t -f test.c:13
-exec-run
-var-create --thread 1 --frame 0 - * bar
-var-list-children var0
-var-evaluate-expression var0.*bar
-exec-continue
-var-update 1 var0
-var-evaluate-expression var0.*bar


Output:
(gdb)
-var-create --thread 1 --frame 0 - * bar
^done,name="var0",numchild="1",value="0x7fffed30",type="int
*",thread-id="1",has_more="0"
(gdb)
-var-list-children var0
^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numchild="0"
,type="int",thread-id="1",has_more="0"}],has_more="0"
(gdb)
-var-evaluate-expression var0.*bar
^done,value="0"

***Value is 0

(gdb)
-exec-continue
^running
(gdb)
=thread-exited,id="1",group-id="i1"
(gdb)
*running,thread-id="all"
(gdb)
=thread-created,id="1",group-id="i1"
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={level="0",addr
="0x00400530",func="main",args=[],file="test.c",fullname="/local/scr
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
(gdb)
-var-update 1 var0
^done,changelist=[]

***No changes

(gdb)
-var-evaluate-expression var0.*bar
^done,value="10"

***Value is 10, even though we reported no changes.

The child shows an update:
(gdb)
-var-update 1 var0.*bar
^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_changed=
"false",has_more="0"}]


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] Documentation LLDB-MI

2017-05-26 Thread Ted Woodward via lldb-dev
lldb-mi uses the gdb/mi interface, which is defined here: 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html . The lldb-mi 
implementation is slightly different in some ways, but nothing that should 
affect what you want to do.

 

Looking at the code (in /tools/lldb-mi/MICmdCmdFile.cpp) for 
-file-exec-and-symbols, I don’t see a way to read a core file with mi commands, 
but you can give an lldb command that will be passed through, something like 
“target create foo.elf -c foo.core”

 

You build lldb-mi the same way you build lldb, just use the lldb-mi target. For 
example, “make lldb-mi”.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Laghzaoui 
Mohammed via lldb-dev
Sent: Friday, May 26, 2017 5:43 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Documentation LLDB-MI

 

Hi Lists,

I have to implement a graphical interface to open the Dump of Macos with LLDB.

I know how to do this using the command line, but this and less productive, I 
found that LLDB-MI little make me an interface to do this need but I did not 
find an example of LLDB-MI in C ++ and How to build LLDB-MI.

To detail our need:

1 - opening of a core dump.

2 -__ reading the value of a memory address.

3 -__ list threads and frames.

4 -__ get assembler of each frame.

  

Thank you in advance for your help

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


Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"

2017-05-22 Thread Ted Woodward via lldb-dev
To expand on Jim's message, "target modules search-paths add" can be used to 
help lldb find  the host-side copies of shared libraries when they're not in 
the same directory as on the target system.

For example, if you have libraries in /usr/lib on the target system, and have 
copies on the host system in /local/scratch/work/debuglibs , you can say
target modules search-paths add /usr/lib /local/scratch/work/debuglibs
and when lldb goes to load (for example) /usr/lib/libc.so, it will try to load 
/local/scratch/work/debuglibs/libc.so from the host machine before trying to 
load through the memory interface.

I found this very helpful when trying to debug dynamic executables on Linux 
running on a Hexagon board, running lldb on x86 Linux or Windows.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Monday, May 22, 2017 5:02 PM
> To: Chunseok Lee 
> Cc: lldb-dev 
> Subject: Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"
> 
> In general, if lldb can find host-side copies of binaries that match the ones 
> it
> finds on the device, it will do all symbol reading against the host copies.  
> In
> the case of an OS X host debugging iOS, lldb uses Spotlight and a few other
> tricks to find the host-side binaries.  You can also use "add-symbol-file" to
> manually point lldb at the host-side symbol files.  If you are reading symbols
> from host-side files, then symbol loading doesn't slow down debugging
> startup that much.
> 
> Presumably, your symbol files are only on the device, so you are reading
> them from memory.  "settings set target.memory-module-load-level" is
> almost what you want, but it applies to ALL shared libraries read from
> memory.  If you can copy the symbol file that contains the
> __jit_debug_register_code to the host you are debugging from, and use
> add-symbol-file to tell lldb about it, then that one should NOT have to be
> read from memory anymore.  Then you could turn "memory-module-load-
> level" to partial or even mininal, and that should get you starting faster.
> 
> The other option would be to extend the setting, so you can say:
> 
> set set target.memory-module-load-level [[lib-name level] [lib-name level]
> ...]
> 
> If there's just one argument, that's equivalent to "all ".
> 
> Jim
> 
> > On May 22, 2017, at 2:35 PM, Chunseok Lee 
> wrote:
> >
> >
> >
> > Thank you for your help.
> > It would be really helpful to me.
> >
> > The reason behind the question is exactly what you mentioned. I am
> > wokring on debugging in devices and it seems that shared library loading(I
> do not know lldb loads symbols lazyly) runs very slowly since my testing
> program depends on so many shared libs.  since I am debuggging with gdbjit
> feature, I do not need shared library loading except one shared lib(which
> contains __jit_debug_register_code symbol) Thus, I want to turn off shred
> lib loading except one shared lib. Is it possible?
> >
> > Thank you.
> >
> > BR,
> > Chunseok Lee
> >
> >
> >
> > 2017. 5. 23. 오전 3:24 Jim Ingham  작성:
> >
> >> We designed lldb to be as lazy as possible in loading symbol information
> from the shared libraries as they get loaded.  If this is causing you 
> problems,
> the first thing to do is to figure out why lldb is pulling in more information
> than you need.  For instance, it looks like on Linux the gdb JIT loading
> breakpoint is getting set with a global search which is pulling in all the 
> symbols
> from all the initially loaded shared libraries.  It would be better to fix 
> things so
> that only explicit user actions (which can be scoped to shared libraries to 
> limit
> the search) pull in symbols so we don't have to fiddle around with turning off
> and on the loading of shared libraries.  Back when we were supporting gdb
> for MacOS I did a lot of work to try to get this right (there are times you 
> really
> need the shared library info - e.g. when something shows up in a backtrace)
> so you have to judiciously re-introduce symbols, or the user experience is
> noticeably degraded.
> >>
> >> It also depends on how far you want to go turning this off.  There's "don't
> look at shared libraries at all" which is what the auto-solib-add variable 
> does
> IIRC.  We also had a fairly extensive mechanism to specify "load-levels" for
> various libraries, which  was more user-friendly but much more work to
> support.  Anyway, it would be easy to just turn this shared library
> notifications - just don't set the dyld load notification breakpoint.  That 
> would
> be the easy part.  But as I said above, you're also going to have to make sure
> you turn it back on for users when some action they request requires it.
> >>

Re: [lldb-dev] Python scripting in Windows LLDB

2017-05-22 Thread Ted Woodward via lldb-dev
My dev machine has both debug and release python exe/lib/dll installed; The VS 
solution made by cmake works fine building debug and release versions of lldb. 
Our bots only have release exe/lib, and create a VS solution with cmake and 
build with msbuild.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Monday, May 22, 2017 3:47 AM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: Zachary Turner <ztur...@google.com>; Vadim Chugunov
> <vadi...@gmail.com>; Hans Wennborg <h...@chromium.org>; LLDB  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Python scripting in Windows LLDB
> 
> This may cause some issues with the multi-configuration generators.
> E.g. a single VS build will create both debug and release configurations. I
> suspect this is the reason why the check is written as it is now.
> 
> I'm not sure what would be the appropriate behavior in this case if only one
> of the pythons is available.
> 
> On 19 May 2017 at 21:42, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> > LLDBConfig.cmake has this:
> >
> >
> >
> >   if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND
> > PYTHON_DEBUG_LIB AND PYTHON_RELEASE_LIB AND
> PYTHON_DEBUG_DLL AND
> > PYTHON_RELEASE_DLL))
> >
> > message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> > set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> > return()
> >
> >   endif()
> >
> >
> >
> > Internally I’ve changed it to:
> >
> >
> >
> >   if (CMAKE_BUILD_TYPE STREQUAL "Debug")
> >
> > if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND
> > PYTHON_DEBUG_DLL))
> >
> >   message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> >   set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> >   return()
> >
> > endif()
> >
> >   else()
> >
> > if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))
> >
> >   message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> >   set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> >   return()
> >
> > endif()
> >
> >   endif()
> >
> >
> >
> > That works with our buildbots building release.
> >
> >
> >
> > Note the release check doesn’t check for the DLL – our installations
> > don’t have the release DLL, so I didn’t put that in.
> >
> >
> >
> > I can push this change upstream if you’d like, Zach.
> >
> >
> >
> > --
> >
> > Qualcomm Innovation Center, Inc.
> >
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >
> >
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> > Zachary Turner via lldb-dev
> > Sent: Friday, May 19, 2017 3:18 PM
> > To: Vadim Chugunov <vadi...@gmail.com>; Hans Wennborg
> > <h...@chromium.org>; LLDB <lldb-dev@lists.llvm.org>
> > Subject: Re: [lldb-dev] Python scripting in Windows LLDB
> >
> >
> >
> > Hmm, I believe it's only supposed to do that if you're doing a debug build.
> > It should only require the Python libraries that match your current build.
> > Is it not doing this?
> >
> >
> >
> > On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev
> > <lldb-dev@lists.llvm.org> wrote:
> >
> > Update: looks like Python detection in CMake now requires debug
> > binaries to be there as well (e.g. python35_d.dll), otherwise Python
> > support gets disabled.  I am wondering if Python the build machine was
> > installed without the debug stuff.
> >
> >
> >
> > On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov <vadi...@gmail.com>
> wrote:
> >
> > Hi!
> >
> >
> >
> > I've just noticed that LLDB from the most recent LLVM Windows snapshot
> > build has Python scripting disabled.
> >
> > Was this done on purpose and for what reason if so?
> >
> >
> >
> > ___
> > 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] Python scripting in Windows LLDB

2017-05-19 Thread Ted Woodward via lldb-dev
LLDBConfig.cmake has this:

 

  if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND 
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))

message("Python installation is corrupt. Python support will be disabled 
for this build.")

set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

return()

  endif()

 

Internally I’ve changed it to:

 

  if (CMAKE_BUILD_TYPE STREQUAL "Debug")

if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))

  message("Python installation is corrupt. Python support will be disabled 
for this build.")

  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

  return()

endif()

  else()

if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))

  message("Python installation is corrupt. Python support will be disabled 
for this build.")

  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

  return()

endif()

  endif()

 

That works with our buildbots building release.

 

Note the release check doesn’t check for the DLL – our installations don’t have 
the release DLL, so I didn’t put that in.

 

I can push this change upstream if you’d like, Zach.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Friday, May 19, 2017 3:18 PM
To: Vadim Chugunov ; Hans Wennborg ; LLDB 

Subject: Re: [lldb-dev] Python scripting in Windows LLDB

 

Hmm, I believe it's only supposed to do that if you're doing a debug build.  It 
should only require the Python libraries that match your current build.  Is it 
not doing this?

 

On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev 
 > wrote:

Update: looks like Python detection in CMake now requires debug binaries to be 
there as well (e.g. python35_d.dll), otherwise Python support gets disabled.  I 
am wondering if Python the build machine was installed without the debug stuff.

 

On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov  > wrote:

Hi!

 

I've just noticed that LLDB from the most recent LLVM Windows snapshot build 
has Python scripting disabled. 

Was this done on purpose and for what reason if so?

 

___
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] remote server crash -> lldb waits forever in accept()

2017-04-28 Thread Ted Woodward via lldb-dev
Hi Chris, Pavel,

I've got a problem launching the hexagon simulator from lldb. It's launched
the same way that debugserver/lldb-server is launched, with reverse connect
on a TCP socket. The user can modify the simulator command line (using
target.run-args), and can easily give a set of options that the simulator
can't handle. In this case the simulator quits before connecting to lldb,
and lldb will wait forever for the connection, since TCPSocket::Accept has
no timeout.

Currently I have a select call before the accept, to make sure there is
activity on the socket. This doesn't feel right with the new changes using
MainLoop, so I wanted to see what the list thinks. I believe it will happen
any time that debugserver/lldb-server quits or crashes before connecting.
That should be easy to test.

This is what I use, right before the call to accept_loop.Run in
TCPSocket::Accept:

NativeSocket accept_socket = -1;
fd_set readset;
FD_ZERO();
for (auto socket : m_listen_sockets) {
  auto fd = socket.first;
  FD_SET(fd, );
  if (fd > accept_socket)
accept_socket = fd;
}
struct timeval timeout = {10, 0};
int result = ::select(accept_socket + 1, , NULL, NULL,
);
if (result == 0) {
  printf("error: timeout waiting for remote server to connect!\n");
  error.SetErrorString("timeout waiting for remote server to connect");
  return error;
} else if (result < 0) {
  printf("error: remote server does not exist!\n");
  SetLastError(error);
  return error;
}


Any thoughts this issue?

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project



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


Re: [lldb-dev] Using LLDB API on windows

2017-04-03 Thread Ted Woodward via lldb-dev
I wonder if lldb isn’t using the windows platform. In the lldb command line, 
load up your target, then type “target list”. I’d like to see what plaform it 
chose, and what the triple is.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Russell Greene [mailto:russellgree...@gmail.com] 
Sent: Monday, April 03, 2017 11:24 AM
To: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] Using LLDB API on windows

 

That makes sense, and I'm sure it works great when using MSVC as a compiler, 
but I think LLDB recognizes mingw as a unix compiler and tries to do 
GDBRemoteCommunication::StartDebugserverProcess when it should be doing 
PlatformWindows::DebugProcess. 

 

Not sure though. All I know is when I try to do a SBTarget::Launch on windows 
under mingw (msys2) it says cannot find lldb-server...

 

-Russell

 

On Mon, Apr 3, 2017 at 9:32 AM Ted Woodward  > wrote:

Hi Russell,

 

I assume you mean for SBTarget::Launch or LaunchSimple to launch a Windows 
application.

 

The short answer is, this already works.

 

SBTarget::Launch calls Target::Launch, which calls DebugProcess in the relevant 
platform. For cases where we use lldb-server, the platform make a call that 
eventually gets to  GDBRemoteCommunication::StartDebugserverProcess to start up 
lldb-server. On Windows, PlatformWindows::DebugProcess calls Process::Launch, 
which (on Windows) will do the correct thing to start up and connect to a 
Windows process.

 

See PlatformWindows::DebugProcess in 
source\Plugins\Platform\Windows\PlatformWindows.cpp and 
ProcessLauncherWIndows::LaunchProcess in 
source\Host\windows\ProcessLauncherWindows.cpp .

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
 ] On Behalf Of Russell Greene via 
lldb-dev
Sent: Sunday, April 02, 2017 4:38 PM
To: lldb-dev@lists.llvm.org  
Subject: [lldb-dev] Using LLDB API on windows

 

Hey so I am developing a project using LLDB as a debugger and am looking to 
make it cross-platform. 

 

As I see it, the LLDB API boots up an instance of lldb-server, but lldb-server 
isn't available on windows. Is there a way to use the LLDB C++ API on windows? 

 

On the status page   I see the lldb 
commandline tool is OK for windows, which uses the LLDB API, how is this 
achieved?

 

-Russell

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


Re: [lldb-dev] Using LLDB API on windows

2017-04-03 Thread Ted Woodward via lldb-dev
Hi Russell,

 

I assume you mean for SBTarget::Launch or LaunchSimple to launch a Windows 
application.

 

The short answer is, this already works.

 

SBTarget::Launch calls Target::Launch, which calls DebugProcess in the relevant 
platform. For cases where we use lldb-server, the platform make a call that 
eventually gets to  GDBRemoteCommunication::StartDebugserverProcess to start up 
lldb-server. On Windows, PlatformWindows::DebugProcess calls Process::Launch, 
which (on Windows) will do the correct thing to start up and connect to a 
Windows process.

 

See PlatformWindows::DebugProcess in 
source\Plugins\Platform\Windows\PlatformWindows.cpp and 
ProcessLauncherWIndows::LaunchProcess in 
source\Host\windows\ProcessLauncherWindows.cpp .

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Russell 
Greene via lldb-dev
Sent: Sunday, April 02, 2017 4:38 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Using LLDB API on windows

 

Hey so I am developing a project using LLDB as a debugger and am looking to 
make it cross-platform. 

 

As I see it, the LLDB API boots up an instance of lldb-server, but lldb-server 
isn't available on windows. Is there a way to use the LLDB C++ API on windows? 

 

On the status page   I see the lldb 
commandline tool is OK for windows, which uses the LLDB API, how is this 
achieved?

 

-Russell

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


[lldb-dev] std::vector formatter question

2017-03-24 Thread Ted Woodward via lldb-dev
On standalone Hexagon (no OS support), we use Dinkumware for the c/c++
library. LLDB isn't able to print out values of a vector:

Process 1 stopped
* thread #1: tid = 0x0001, 0x519c vector.elf`main + 76 at vector.cpp:10,
stop reason = step in
frame #0: 0x519c vector.elf`main + 76 at vector.c:10
   7vector v;
   8v.push_back(2);
   9v.push_back(1);
-> 10   cout << v[0] << " " << v[1] << endl;
   11   return 0;
   12   }
 (lldb) fr v v
(std::vector) v = size=0 {}

When I run on x86 linux built with gcc, I get:
(lldb) fr v v
(std::vector) v = size=2 {
  [0] = 2
  [1] = 1
}


My guess is Dinkumware's vector type is just a little bit different from
libstdc++/libcxx, so the standard formatters don't do the right thing. Where
are the vector formatters defined, and how does LLDB determine which
one to use?


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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


Re: [lldb-dev] LLDB/NetBSD extended set of tasks

2017-03-17 Thread Ted Woodward via lldb-dev


From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel 
Labath via lldb-dev
Sent: Friday, March 17, 2017 4:48 AM

> On 16 March 2017 at 21:43, Kamil Rytarowski  wrote:
>> I imagined a possible flow of ResumeAction calls like:
>> [Generic/Native framework knows upfront the image of threads within
>> debuggee]
>>  - Resume Thread 2 (PT_RESUME)
>>  - Suspend Thread 3 (PT_SUSPEND)
>>  - Set single-step Thread 2 (PT_SETSTEP)
>>  - Set single-step Thread 4 (PT_SETSTEP)
>>  - Clear single-step Thread 5 (PT_CLEARSTEP)
>>  - Resume & emit signal SIGIO (PT_CONTINUE)
>>
>> In other words: setting properties on threads and pushing the
>> PT_CONTINUE button at the end.

> None of this is really NetBSD-specific, except the whole-process signal at 
> the end (which I am going to ignore for now). I mean, the implementation of 
> it is different, but there is no reason why someone would not want to perform 
> the same set of actions on Linux for instance. I think most of the work here 
> should be done on the client. Then, when the user issues the final 
> "continue", the client sends something like $vCont;s:2;s:4;c:5. Then it's up 
> to the server to figure out how execute these actions. On NetBSD it would 
> execute the operations you mention above, while on linux it would do 
> something like ptrace(PTRACE_SINGLESTEP, 2); ptrace(PTRACE_SINGLESTEP, 4); 
> ptrace(PTRACE_CONTINUE, 5); (linux lldb-server already supports this 
> actually, although you may have a hard time convincing the client to send a 
> packet like that).

The big problem with this sequence is non-stop mode. To continue thread 5 while 
threads 2 and 4 are stepping, and thread 3 is stopped is not legal using 
all-stop mode. lldb only supports non-stop mode in the gdb-remote 
communications layer; the guts of the debugger do not support it, and could get 
very confused when threads 2 and 4 stop, but thread 5 is still running.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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


Re: [lldb-dev] non-stop mode with lldb-mi?

2017-02-03 Thread Ted Woodward via lldb-dev
I think the remote stub only sends extra stop replies in response to a vStopped 
packet. Here is a stop for 2 threads hitting a common breakpoint:

<  51> send packet: $vCont;c:10b6;c:10f8;c:00b3;c:00b2;c:00b1;c:00b0#e0
<   1> read packet: +
<   6> read packet: $OK#9a
<   1> send packet: +
<  58> read packet: %Stop:T052a:c8f4f5e0;1e:90de101b;1d:48dd101b;thread:af;#1d
<   1> send packet: +
<  12> send packet: $vStopped#55
<   1> read packet: +
<  53> read packet: $T052a:c8f4f5e0;1e:309c101b;1d:e89a101b;thread:b0;#d8
<   1> send packet: +
<  12> send packet: $vStopped#55
<   1> read packet: +
<   6> read packet: $OK#9a

So we won't get any spurious stops in the middle of processing.

"Experimental feature, not tested" is noted - I'll mention that in my meeting 
today.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Friday, February 03, 2017 1:22 PM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: Greg Clayton <gclay...@apple.com>; LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> 
> 
> > On Feb 3, 2017, at 10:51 AM, Ted Woodward
> <ted.woodw...@codeaurora.org> wrote:
> >
> > I'm working on plumbing the existing non-stop mode switch (target.non-
> stop-mode) to lldb-mi, to give Eclipse access to non-stop mode.
> >
> > The remote OS is very thread-heavy, and the remote stub doesn't limit the
> debugger to the current process - because there isn't one, from the stub's
> point of view. Just a collection of threads. In all-stop mode, if a 2nd thread
> hits a breakpoint, it will send back a 2nd stop reply, which confuses lldb
> (rightly so). In non-stop mode, it handles things correctly. So we'll just 
> have
> to live with the possible missed breakpoint issue.
> 
> We tried to keep the possibility of a non-stop mode in mind when designing
> lldb, but I know there are places in lldb at present that assume that if you 
> get
> a "stop" event you won't get another stop event till lldb issues a run.  We 
> try
> not to fall over completely if we get events we don't expect, but we're more
> likely to just discard them than do the right thing.  There also don't appear 
> to
> be any tests running programs in non-stop mode and exercising their
> behavior, so any extent to which it works will be accidental and unstable.
> 
> Seems like this is an experimental feature at best, and should be marked as
> such.
> 
> Jim
> 
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >
> >> -Original Message-
> >> From: jing...@apple.com [mailto:jing...@apple.com]
> >> Sent: Friday, February 03, 2017 10:58 AM
> >> To: Greg Clayton <gclay...@apple.com>
> >> Cc: Ted Woodward <ted.woodw...@codeaurora.org>; LLDB  >> d...@lists.llvm.org>
> >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> >>
> >>
> >>> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Non-stop mode is a huge change to the core of LLDB isn’t it. I think
> >>> you
> >> might think this is easier than it actually is to enable in LLDB?
> >>>
> >>> Is non-stop mode where you can leave some threads running while
> >>> others
> >> are stopped? The biggest issue with this is to do it right we need to
> >> be able to emulate instructions so that if 3 threads hit breakpoints,
> >> we would need to emulate the instruction that used to be at the
> >> breakpoint in LLDB since we can’t remove the breakpoint (unless you
> >> stop the other threads which defeats the purpose of non-stop mode)
> >> without the other 2 threads possibly missing the breakpoint while you
> >> disable breakpoint, single step, enable breakpoint.
> >>
> >> That is just one of the many things that will have to be changed to
> >> support non-stop mode.  For now, non-stop mode is only likely to work
> >> reliably if the threads you are allowing to run never stop - hit
> >> breakpoints, crash or whatever - so worrying about missing breakpoints is
> a second order problem.
> >>
> >> Anyway, even as it is it has some utility - presumably you're using
> >> it because you have some threads in

Re: [lldb-dev] non-stop mode with lldb-mi?

2017-02-03 Thread Ted Woodward via lldb-dev
I'm working on plumbing the existing non-stop mode switch 
(target.non-stop-mode) to lldb-mi, to give Eclipse access to non-stop mode.

The remote OS is very thread-heavy, and the remote stub doesn't limit the 
debugger to the current process - because there isn't one, from the stub's 
point of view. Just a collection of threads. In all-stop mode, if a 2nd thread 
hits a breakpoint, it will send back a 2nd stop reply, which confuses lldb 
(rightly so). In non-stop mode, it handles things correctly. So we'll just have 
to live with the possible missed breakpoint issue.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Friday, February 03, 2017 10:58 AM
> To: Greg Clayton <gclay...@apple.com>
> Cc: Ted Woodward <ted.woodw...@codeaurora.org>; LLDB  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> 
> 
> > On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > Non-stop mode is a huge change to the core of LLDB isn’t it. I think you
> might think this is easier than it actually is to enable in LLDB?
> >
> > Is non-stop mode where you can leave some threads running while others
> are stopped? The biggest issue with this is to do it right we need to be able 
> to
> emulate instructions so that if 3 threads hit breakpoints, we would need to
> emulate the instruction that used to be at the breakpoint in LLDB since we
> can’t remove the breakpoint (unless you stop the other threads which
> defeats the purpose of non-stop mode) without the other 2 threads possibly
> missing the breakpoint while you disable breakpoint, single step, enable
> breakpoint.
> 
> That is just one of the many things that will have to be changed to support
> non-stop mode.  For now, non-stop mode is only likely to work reliably if the
> threads you are allowing to run never stop - hit breakpoints, crash or
> whatever - so worrying about missing breakpoints is a second order problem.
> 
> Anyway, even as it is it has some utility - presumably you're using it because
> you have some threads in your program that can't stop, so you're not likely to
> want them to hit breakpoints anyway...  But the current help text for the
> non-stop setting should probably include some appropriate caveats.
> 
> Jim
> 
> 
> >
> > Greg
> >
> >> On Feb 3, 2017, at 7:54 AM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >>
> >> That turns on and off async, but not non-stop.
> >>
> >> I’m working on adding support for –gdb-set and –gdb-show non-stop,
> and will post my changes on phabricator when I’m done.
> >>
> >> --
> >> Qualcomm Innovation Center, Inc.
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora
> Forum, a Linux Foundation Collaborative Project
> >>
> >> From: Ilia K [mailto:ki.s...@gmail.com]
> >> Sent: Wednesday, February 01, 2017 11:13 PM
> >> To: Ted Woodward <ted.woodw...@codeaurora.org>
> >> Cc: LLDB <lldb-dev@lists.llvm.org>
> >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> >>
> >> Please check `-gdb-set target.async` option. Probably that's what you
> need.
> >>
> >> On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >>> Does lldb-mi support non-stop mode?
> >>>
> >>> If so, is there a way to set it besides “settings set target.non-stop-mode
> true”?
> >>>
> >>> --
> >>> Qualcomm Innovation Center, Inc.
> >>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora
> Forum, a Linux Foundation Collaborative Project
> >>>
> >>>
> >>> ___
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>>
> >>
> >>
> >>
> >> --
> >> - Ilia
> >> ___
> >> 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] non-stop mode with lldb-mi?

2017-02-03 Thread Ted Woodward via lldb-dev
That turns on and off async, but not non-stop.

 

I’m working on adding support for –gdb-set and –gdb-show non-stop, and will 
post my changes on phabricator when I’m done.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Ilia K [mailto:ki.s...@gmail.com] 
Sent: Wednesday, February 01, 2017 11:13 PM
To: Ted Woodward <ted.woodw...@codeaurora.org>
Cc: LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] non-stop mode with lldb-mi?

 

Please check `-gdb-set target.async` option. Probably that's what you need.

 

On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev 
<lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote:

Does lldb-mi support non-stop mode?

 

If so, is there a way to set it besides “settings set target.non-stop-mode 
true”?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 


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





 

-- 

- Ilia

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


[lldb-dev] non-stop mode with lldb-mi?

2017-02-01 Thread Ted Woodward via lldb-dev
Does lldb-mi support non-stop mode?

 

If so, is there a way to set it besides "settings set target.non-stop-mode
true"?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Ted Woodward via lldb-dev
Try "image search-paths add" as a replacement for "set solib-search-path"

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene
Birukov via lldb-dev
Sent: Friday, January 20, 2017 12:35 PM
To: Pavel Labath 
Cc: rd...@microsoft.com; LLDB 
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

 

Hello Pavel,

 

Thanks for the reply. Unfortunately I cannot share the core dump with you.

 

Yes, Rob has figured that LLDB does not find this shared library and that
causes the problem. To understand what is going on here, I need to add one
more detail that was missing from my original post: this is a cross-machine
investigation. I.e. the core dump collected on one machine (CentOs) was sent
to another

(Ubuntu) where I tried to open it.

 

LLDB opens the executable without paying attention that there is a core dump
attached and tries to locate shared libraries. Apparently the ones that
exist on my machine are not good, so it then looks in the directory with the
executable itself. There is no way to "set solib-search-path" as we do on
GDB and force it to look somewhere else. After we dumped all the shared
libraries in the folder with the executable LLDB was able to open the dump.
This is a bit inconvenient, but works as a workaround for now.

 

Sent from Outlook  

 

  _  

From: Pavel Labath  >
Sent: Friday, January 20, 2017 6:55 AM
To: Eugene Birukov
Cc: LLDB; rd...@microsoft.com  
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump 

 

Hello Eugene,

I have been aware of this problem for a while, but I haven't found a
really good solution so far, partially due to lack of a good repro
case -- I think your analysis has helped me with this, and I am
finally starting to piece together the sequence of events leading to
the crash. If you have a repro case you can send me, it would be even
better.

I don't really have an answer to your quesiton, but here are a couple
of observations (the details might be a bit sketchy - it's been a long
time since I looked at this):
- reading the section headers from memory should be a fallback.
Normally we try first to locate the file on disk and read data from
there. This was mainly added for the vdso "module", as that is not
really present on disk. One of the ways of fixing this crash could be
to figure out why we are not finding the c++abi binary on disk.

- we trust far too much the data we read from inferior memory. We
should be much more careful when doing things based on "untrusted"
data. Checking the memory maps as you suggest could be one idea.
Another option I am considering is teaching ReadMemory to allocate
data in (reasonably sized, say a couple of MB) chunks. Right now it
allocates the full buffer without even trying to read the memory. If
it instead tried to read data in smaller chunks it would error out due
to failure to read inferior memory long before it gets a chance to
exhaust own address space. (With a sufficiently large chunk, this
should not affect performance of normal reads).

hope that helps,
pl



On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
 > wrote:
> Hi,
>
>
> I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> greatly appreciate any advise how to deal with the problem or what else I
> should look at.
>
>
> The core dump was produced by GDB and GDB itself opens it without
problems.
>
>
> So, during loading the core we call
> DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> modules and does some processing. In the course of actions, it calls the
> ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> load section headers and read string table. Well, it gets some garbage in
> the section header struct and tries to allocate 1.5TB memory which causes
> operator new throw.
>
>
> So, why we get garbage?
>
>
> The module in question is libc++abi.so.1:
>
>
> 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> I->link_addr, I->base_addr, true);
>
> (gdb) p I->file_spec
>
> $95 = {
>
>   m_directory = {
>
> m_string = 0x829a58 "... redacted ..."
>
>   },
>
>   m_filename = {
>
> m_string = 0x7cc9e8 "libc++abi.so.1"
>
>   },
>
>   m_is_resolved = false,
>
>   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
>
> }
>
>
> The module header lives at address 0x7f699a27  and looks OK. The
section
> headers are supposed to be at offset 2495600 == 0x261470
>
>
> $96 = (const elf::ELFHeader &) @0x953a78: {
>
>   e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
>
>   e_entry = 33392,
>
>   e_phoff = 64,
>
>   e_shoff = 

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-12 Thread Ted Woodward via lldb-dev
The compiler redistributable is also widely available:

 

https://www.microsoft.com/en-us/download/details.aspx?id=48145

 

The python 3.5 dll would still use the runtime dll; lldb should do the same. 
I’ve had crashes in the past because lldb and python used different runtimes.

 

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Vadim 
Chugunov via lldb-dev
Sent: Wednesday, January 11, 2017 8:49 PM
To: Zachary Turner 
Cc: LLDB 
Subject: Re: [lldb-dev] Prebuilt binary for Windows

 

 

 

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner  > wrote:

Ahh, that would make sense as well, since LLDB links against liblldb as a dll.  
Don't see a good solution to this short of forcing dynamic linking.  liblldb 
has to be a dll because it needs to be visible to python as an extension 
module.  And if it's a dll and uses static linking, then we would have to 
require that lldb.exe not pass file handles across the dll boundary.  If that's 
easy then great, but I suspect it probably isn't.  

 

Honestly dynamic linking was created to solve exactly these kinds of problems.  
Yes there's the redist issue if on Windows < 10, but it seems like a small 
price to pay for something that doesn't have weird subtle bugs.  And as time 
goes on, more and more people will be on windows 10 anyway.

 

Does the redistributable issue present a challenge for your use case?

 

There are actually two part of the MSVC runtime: the Universal C Runtime (UCRT) 
and the compiler-specific, VCRUNTIME140.   The former is widely available 
(comes with Windows 10, and had been pushed to Vista, 7 and 8 via Windows 
Update).  The latter is tied to the compiler version and must still be 
redistributed with programs.   Ideally, LLDB would use dynamic UCRT + static 
VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported configuration 
(discussion of this issue in Python bug tracker 
 ).   Looks like Python folks opted for 
shipping VCRUNTIME140.DLL in their install directory.

 

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


Re: [lldb-dev] test decorator working on linux, but not on windows

2017-01-06 Thread Ted Woodward via lldb-dev
Bottom line: lldbutil.is_exe() does not think “foo” is an exe on windows when 
“foo.exe” is.

 

 

 

print("***compiler is:", self.getCompiler(), file=sys.stderr)

 

***compiler is: 
C:\lldb\8.0\llvm\tools\lldb\packages\Python\lldbsuite\test\lang\c\typedef

 

self.getCompiler() is returning the test directory.

 

So, _decorateTest’s line:

skip_for_compiler = _match_decorator_property(compiler, 
self.getCompiler()) and self.expectedCompilerVersion(compiler_version)

is trying to match with the test directory.

 

On Linux I get this:

***compiler is: 
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/toolset-4199/Tools/bin/clang-3.9

The path to the compiler (hexagon-clang is a symlink to clang-3.9).

 

Builder_base.getCompiler is:

def getCompiler():

"""Returns the compiler in effect the test suite is running with."""

compiler = os.environ.get("CC", "clang")

compiler = lldbutil.which(compiler)

return os.path.realpath(compiler)

 

os.environ.get returns 
r:/internal/branch-8.0/windows/latest/Tools/bin/hexagon-clang, but 
lldbutil.which returns None.

def which(program):

"""Returns the full path to a program; None otherwise."""

fpath, fname = os.path.split(program)

if fpath:

if is_exe(program):

return program

else:

for path in os.environ["PATH"].split(os.pathsep):

exe_file = os.path.join(path, program)

if is_exe(exe_file):

return exe_file

return None

 

The problem is the compiler – I specified hexagon-clang, not hexagon-clang.exe, 
so is_exe returns false.

def is_exe(fpath):

"""Returns True if fpath is an executable."""

return os.path.isfile(fpath) and os.access(fpath, os.X_OK)

 

 

 

My run line:

c:\lldb\8.0\35\Debug\libexec\python_d dotest.py -A v60 -C 
r:/internal/branch-8.0/windows/latest/Tools/bin/hexagon-clang --executable 
c:\lldb\8.0\35\Debug\bin\lldb.exe -t -v -p Testtypedef.py

 

Changing it to hexagon-clang.exe solved the problem.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Friday, January 06, 2017 12:17 PM
To: Ted Woodward <ted.woodw...@codeaurora.org>; LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] test decorator working on linux, but not on windows

 

You will probably need to debug the python code to figure out why this is 
happening.  Start with this line in 
lldb/packages/Python/lldbsuite/test/decorators.py

def _decorateTest(mode,

  bugnumber=None, oslist=None, hostoslist=None,

  compiler=None, compiler_version=None,

  archs=None, triple=None,

  debug_info=None,

  swig_version=None, py_version=None,

  macos_version=None,

  remote=None):

...

skip_for_compiler = _match_decorator_property(

        compiler, self.getCompiler()) and 
self.expectedCompilerVersion(compiler_version)

 

 

On Fri, Jan 6, 2017 at 10:11 AM Ted Woodward via lldb-dev 
<lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote:

packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this decorator:

 

@expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238 
<http://llvm.org/pr19238> ")

 

On Linux, I’m building with hexagon-clang, and this decorator fires, so the 
test is xfailed.

On Windows, I’m building with hexagon-clang.exe, and this decorator is 
evidently not firing, because the test fails instead of being xfailed.

 

Linux is using Python 2.7.8. Windows is using Python 3.5.1.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto: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] test decorator working on linux, but not on windows

2017-01-06 Thread Ted Woodward via lldb-dev
packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this
decorator:

 

@expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238")

 

On Linux, I'm building with hexagon-clang, and this decorator fires, so the
test is xfailed.

On Windows, I'm building with hexagon-clang.exe, and this decorator is
evidently not firing, because the test fails instead of being xfailed.

 

Linux is using Python 2.7.8. Windows is using Python 3.5.1.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


Re: [lldb-dev] LLDB bare-metal and 'load' command

2016-12-16 Thread Ted Woodward via lldb-dev
Hi Abid,

How are you communicating with the ARM? lldb->gdbserver->jtag probe? We've 
discussed doing that kind of thing with Hexagon, but we're nowhere near 
implementing it.

"process launch" on linux can download the target to the remote machine when 
connected in platform mode. If you make your remote server and platform do 
that, it should handle what you need.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Abid,
> Hafiz via lldb-dev
> Sent: Friday, December 16, 2016 11:00 AM
> To: Greg Clayton (gclay...@apple.com) 
> Cc: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] LLDB bare-metal and 'load' command
> 
> Hi Greg,
> I was trying to do some bare-metal debugging with LLDB and an ARM board. I
> noticed that LLDB does not have a command similar to 'load' command of
> GDB. Searching the mailing list, it seems that this issue has been discussed
> before.
> 
> http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html
> 
> Has any such command been added in LLDB since that discussion? If not,
> then I would like to take a stab at adding this command in LLDB proper. I was
> wondering where such command will make most sense. Should it be added
> to some existing group like 'process' or 'image' or be a stand-alone
> command?
> 
> Thanks,
> Abid
> ___
> 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 4.0.0 crashes on Windows 7

2016-12-06 Thread Ted Woodward via lldb-dev

I've also never seen either problem. I'm not debugging Windows apps, but 
Hexagon apps, running lldb and the Hexagon simulator on Win7.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eli
> Zaretskii via lldb-dev
> Sent: Tuesday, December 06, 2016 10:39 AM
> To: Zachary Turner 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
> 
> > From: Zachary Turner 
> > Date: Tue, 06 Dec 2016 16:22:51 +
> >
> > I have never seen either of those problems, but I can test it out and see 
> > if I
> can reproduce.
> 
> Thanks.
> 
> If you are unable to reproduce, I wonder why it happens to me.  The system
> where I installed lldb is just a vanilla Windows 7 box.
> ___
> 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-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Ted Woodward via lldb-dev
LLDB_DEFAULT_PYTHONHOME is an internal thing; I haven’t upstreamed it – for a 
while, it conflicted with Zach’s implementation, but I redid it, and everything 
is happy now. If you think it would be useful, I could upstream it. It’s fairly 
small, and plays nice with Zach’s Python stuff.

 

The problem it solves is “where is my python?” on Windows. If you know you’ll 
be running on a system with the same python installation as the build system, 
then you don’t need it. Or if you can tell your users to install the same 
python you built with, in the same location, you’re OK. I can’t do that, so 
instead I ship python, and tell lldb where to find it at build time.

 

We copy over the full site-packages directory that is created by the lldb 
build, and end up with this directory structure:

bin/lldb.exe

bin/liblldb.dll

bin/python35.dll

lib/python35

lib/site-packages

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Monday, November 28, 2016 12:17 PM
To: Vadim Chugunov ; Hans Wennborg 
Cc: Ted Woodward ; Reid Kleckner 
; LLDB 
Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

 

I overlooked that part of it, but yes that is another separate issue.  (BTW, 
_lldb.pyd is simply a symlink to liblldb.dll).  

 

In any case, yea I think the entire lib/site-packages folder needs to be 
included.

 

On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov  > wrote:

Please correct me if I'm wrong, but isn't the issue here that LLDB's Python 
support files don't get packaged into the Windows installer?   Does packaging 
them somehow depend on knowing what the Python installation path is?

 

On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  > wrote:

The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.

I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.

On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner  > wrote:
> So it sounds like you're saying that in order for Python support to work as
> part of an LLDB shipped in the installer, we need to do set 3 variables at
> CMake time.
>
> 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> 2) -DPYTHON_HOME = 
> 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>
> Now because of #3, the lldb shipped in the installer will use the PYTHONHOME
> system environment variable to locate python, which must point to a valid
> Python 3.5 installation.  Is this correct?
>
> On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward   >
> wrote:
>>
>> Windows has no concept of a default python installation, and I can’t be
>> sure what version of python my users have, if any, so I need to solve 2
>> problems:
>>
>> 1)  Where is python when I’m building?
>>
>> 2)  Where is python when I’m running?
>>
>>
>>
>> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my
>> python installation (on our buildbots, c:/python351).
>>
>>
>>
>> #2 only needs to be solved if the machine you’re running on doesn’t have
>> the same python installation, in PYTHON_HOME above. To do that, I’ve added
>> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro
>> down to InitializePythonHome in
>> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
>> call Py_SetPythonHome with it. My installations have the python dll and
>> python library directory. We put the library in /lib/python35 and
>> the dll in /bin.
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com  ]
>> Sent: Wednesday, November 23, 2016 12:40 PM
>> To: Vadim Chugunov  >
>> Cc: Reid Kleckner  >; Hans Wennborg 
>>  >;
>> LLDB  >; Ted 
>> Woodward  >
>> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>
>>
>>
>> I believe the way to fix this is going to be building LLDB for the
>> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>
>>
>>
>> +Ted, since I believe he is one of the few people currently using this
>> flag.
>>
>> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov > 

Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server

2016-11-16 Thread Ted Woodward via lldb-dev

I tried having SetExecutableModule call ModuleDidLoad after appending the 
executable to m_images, but it didn't work. It eventually drills down to call 
GetSectionLoadList, which is empty. Probably because the module list got 
cleared. Any thoughts on how to clean up the new module list, and add the 
breakpoints back?

That leads me to think that other modules besides the executable would just be 
lost.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Wednesday, November 16, 2016 2:12 PM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] "image search-paths add" removes all breakpoints
> from remote server
> 
> 
> > On Nov 16, 2016, at 12:03 PM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > Is “image search-paths add” supposed to remove all breakpoints from the
> remote server? I don’t think it should be doing this.
> >
> > PathMappingList::Append calls Target::ImageSearchPathsChanged, which
> calls Target::SetExecutableModule, which calls Target::ClearModules, which
> removes the breakpoints. But SetExecutableModule doesn’t restore the
> breakpoints.
> >
> >
> >
> > This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
> Packet log edited to remove chaff.
> >
> > (lldb) log enable gdb-remote packets
> > (lldb) process launch –s
> > Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
> > (lldb) process status
> > Process 18766 stopped
> > * thread #1, name = 'factlin', stop reason = signal SIGSTOP
> > frame #0: 0x77ddb6b0
> > ->  0x77ddb6b0: movq   %rsp, %rdi
> > 0x77ddb6b3: callq  0x77ddf010
> > 0x77ddb6b8: movq   %rax, %r12
> > 0x77ddb6bb: movl   0x2215ff(%rip), %eax
> > (lldb) b main
> > <  15> send packet: $Z0,400586,1#4a
> > <   6> read packet: $OK#9a
> > Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
> > 0x00400586
> > (lldb) br l
> > Current breakpoints:
> > 1: name = 'main', locations = 1, resolved = 1, hit count = 0
> >   1.1: where = factlin`main + 22 at factorial.c:32, address =
> > 0x00400586, resolved, hit count = 0
> > (lldb) image search-paths add /local /tmp <  15> send packet:
> > $z0,400586,1#6a
> > <   6> read packet: $OK#9a
> > <  15> send packet: $z0,400410,1#5c
> > <   6> read packet: $OK#9a
> > (lldb) br l
> > Current breakpoints:
> > 1: name = 'main', locations = 1
> >   1.1: where = factlin`main + 22 at factorial.c:32, address =
> > factlin[0x00400586], unresolved, hit count = 0
> > (lldb) c
> > <   5> send packet: $c#63
> > Process 18766 resuming
> > Factorial of 10 is 3628800
> > <   7> read packet: $W00#b7
> > Process 18766 exited with status = 0 (0x)
> 
> This is a distinction without much difference, but the break list output is
> actually telling you somebody forgot to re-install the breakpoints.  Note the
> state went from resolved (i.e. there is a site in the targeted process for 
> this
> breakpoint location) to unresolved.  Still a bug, but the breakpoints aren't
> lying to you...
> 
> When you added search paths, all the breakpoints needed to be re-set, since
> the symbol world might have changed.  But apparently only the removal part
> is getting done.
> 
> Jim
> 
> 
> >
> > As you can see, the breakpoint at main was removed on lldb-server, but
> shows as active in the breakpoint list. When I continue, the breakpoint isn’t
> hit, and the target runs to completion.
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> > ___
> > 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] "image search-paths add" removes all breakpoints from remote server

2016-11-16 Thread Ted Woodward via lldb-dev
Is "image search-paths add" supposed to remove all breakpoints from the
remote server? I don't think it should be doing this.

 

PathMappingList::Append calls Target::ImageSearchPathsChanged, which calls
Target::SetExecutableModule, which calls Target::ClearModules, which removes
the breakpoints. But SetExecutableModule doesn't restore the breakpoints.

 

 

 

This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
Packet log edited to remove chaff.

 

(lldb) log enable gdb-remote packets

(lldb) process launch -s

Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)

(lldb) process status

Process 18766 stopped

* thread #1, name = 'factlin', stop reason = signal SIGSTOP

frame #0: 0x77ddb6b0

->  0x77ddb6b0: movq   %rsp, %rdi

0x77ddb6b3: callq  0x77ddf010

0x77ddb6b8: movq   %rax, %r12

0x77ddb6bb: movl   0x2215ff(%rip), %eax

(lldb) b main

<  15> send packet: $Z0,400586,1#4a

<   6> read packet: $OK#9a

Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586

(lldb) br l

Current breakpoints:

1: name = 'main', locations = 1, resolved = 1, hit count = 0

  1.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 0 

(lldb) image search-paths add /local /tmp

<  15> send packet: $z0,400586,1#6a

<   6> read packet: $OK#9a

<  15> send packet: $z0,400410,1#5c

<   6> read packet: $OK#9a

(lldb) br l

Current breakpoints:

1: name = 'main', locations = 1

  1.1: where = factlin`main + 22 at factorial.c:32, address =
factlin[0x00400586], unresolved, hit count = 0 

(lldb) c

<   5> send packet: $c#63

Process 18766 resuming

Factorial of 10 is 3628800

<   7> read packet: $W00#b7

Process 18766 exited with status = 0 (0x)

 

As you can see, the breakpoint at main was removed on lldb-server, but shows
as active in the breakpoint list. When I continue, the breakpoint isn't hit,
and the target runs to completion.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


Re: [lldb-dev] LLDB can't find source...but it can?

2016-10-17 Thread Ted Woodward via lldb-dev
What's the compiler bug? I see a DW_AT_subprogram entry for main_gdbserver, and 
linetable entries for the addresses of main_gdbserver. 

I've found that getting DWARF compiler bugs fixed can be...challenging. The 
better I can narrow it down for the compiler engineers, the better. 

This is clang that was ToT about 2 months ago, BTW.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Monday, October 17, 2016 11:03 AM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
> 
> This is a compiler bug.
> 
> > On Oct 14, 2016, at 12:14 PM, Ted Woodward
> <ted.woodw...@codeaurora.org> wrote:
> >
> >> Probably a debug info problem. Before we know to look for addresses
> >> within a compile unit, the compile unit must claim it has a function
> >> that contains this address. So check the DWARF in the compile unit
> >> that contains 0x114720 (not sure if there is a lookup by address in
> >> llmv-dwarfdump?) and make sure there is a DW_TAG_subprogram that
> contains this address.
> >>
> >> Greg
> >
> > I'm changing gears here - I'm having the same issue with lldb-server, and
> it's smaller, so I'm looking at that.
> >
> > main calls main_gdbserver, which is in tools/lldb-server/lldb-
> gdbserver.cpp, and has no line table info, according to lldb's list comm info.
> >
> > 4: name = 'main_gdbserver', locations = 2
> >  4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address =
> > 0x00048964, unresolved, hit count = 0
> >  4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address =
> > 0x00048964, unresolved, hit count = 0
> >
> > (lldb) list 0x48964
> > error: address resolves to lldb-server[0x00048964], but there is no
> line table information available for this address.
> >
> >
> > main_gdbserver has a DW_AT_subprogram entry:
> > 0x000306a4:   DW_TAG_subprogram [106] *
> >DW_AT_low_pc [DW_FORM_addr]  (0x00048944)
> >DW_AT_high_pc [DW_FORM_data4](0x0da4)
> >DW_AT_frame_base [DW_FORM_exprloc]   (<0x1> 6e )
> >DW_AT_linkage_name [DW_FORM_strp](
> .debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
> >DW_AT_name [DW_FORM_strp]( .debug_str[0x00065792] =
> "main_gdbserver")
> >DW_AT_decl_file [DW_FORM_data1]
>   ("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-
> server/lldb-gdbserver.cpp")
> >DW_AT_decl_line [DW_FORM_data2]  (326)
> >DW_AT_type [DW_FORM_ref4](cu + 0x003b => {0x00011c13})
> >DW_AT_external [DW_FORM_flag_present](true)
> >
> > And a linetable entry:
> > 0x00048944327  0  1   0 0  is_stmt
> > 0x0004896432811  1   0 0  is_stmt 
> > prologue_end
> >
> >
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >> -Original Message-
> >> From: Greg Clayton [mailto:gclay...@apple.com]
> >> Sent: Tuesday, October 11, 2016 1:34 PM
> >> To: Ted Woodward <ted.woodw...@codeaurora.org>
> >> Cc: LLDB <lldb-dev@lists.llvm.org>
> >> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
> >>
> >>
> >>> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Background – I’m working on getting LLDB to run on Hexagon Linux,
> >>> built
> >> with an LLVM toolchain. We’re using libc++ and MUSL. The loader is a
> >> bit squirrelly right now, so I’ve built LLDB statically.
> >>>
> >>> I’ve got full source debugging in the driver, but when I step into
> >> SBDebugger::Create, I don’t have any source. I’ve got symbols:
> >>> (lldb) bt
> >>> * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool)
> >>> + 16,
> >> stop reason = breakpoint 2.1
> >>>  * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
> >>>frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124
> >>> at
&g

Re: [lldb-dev] LLDB can't find source...but it can?

2016-10-14 Thread Ted Woodward via lldb-dev
> Probably a debug info problem. Before we know to look for addresses within
> a compile unit, the compile unit must claim it has a function that contains 
> this
> address. So check the DWARF in the compile unit that contains 0x114720 (not
> sure if there is a lookup by address in llmv-dwarfdump?) and make sure
> there is a DW_TAG_subprogram that contains this address.
> 
> Greg

I'm changing gears here - I'm having the same issue with lldb-server, and it's 
smaller, so I'm looking at that.

main calls main_gdbserver, which is in tools/lldb-server/lldb-gdbserver.cpp, 
and has no line table info, according to lldb's list comm info.

4: name = 'main_gdbserver', locations = 2
  4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address = 
0x00048964, unresolved, hit count = 0
  4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address = 
0x00048964, unresolved, hit count = 0

(lldb) list 0x48964
error: address resolves to lldb-server[0x00048964], but there is no 
line table information available for this address.


main_gdbserver has a DW_AT_subprogram entry:
0x000306a4:   DW_TAG_subprogram [106] *
DW_AT_low_pc [DW_FORM_addr] (0x00048944)
DW_AT_high_pc [DW_FORM_data4]   (0x0da4)
DW_AT_frame_base [DW_FORM_exprloc]  (<0x1> 6e )
DW_AT_linkage_name [DW_FORM_strp]   ( 
.debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x00065792] = 
"main_gdbserver")
DW_AT_decl_file [DW_FORM_data1] 
("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-server/lldb-gdbserver.cpp")
DW_AT_decl_line [DW_FORM_data2] (326)
DW_AT_type [DW_FORM_ref4]   (cu + 0x003b => {0x00011c13})
DW_AT_external [DW_FORM_flag_present]   (true)

And a linetable entry:
0x00048944327  0  1   0 0  is_stmt
0x0004896432811  1   0 0  is_stmt prologue_end



--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Tuesday, October 11, 2016 1:34 PM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
> 
> 
> > On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > Background – I’m working on getting LLDB to run on Hexagon Linux, built
> with an LLVM toolchain. We’re using libc++ and MUSL. The loader is a bit
> squirrelly right now, so I’ve built LLDB statically.
> >
> > I’ve got full source debugging in the driver, but when I step into
> SBDebugger::Create, I don’t have any source. I’ve got symbols:
> > (lldb) bt
> > * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16,
> stop reason = breakpoint 2.1
> >   * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
> > frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124 at
> Driver.cpp:150
> > frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at
> Driver.cpp:1350
> > frame #3: 0x04744384 lldb`__libc_start_main + 48
> >
> > list SBDebugger::Create fails, but list SBDebugger::Create(bool) gives me
> source.
> > (lldb) list SBDebugger::Create
> > (lldb) list SBDebugger::Create(bool)
> > File:
> \local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger.cp
> p
> >172  return SBDebugger::Create(false, nullptr, nullptr);
> >173  }
> >174
> >175  SBDebugger
> >176  SBDebugger::Create(bool source_init_files)
> >177  {
> >178  return SBDebugger::Create (source_init_files, nullptr, nullptr);
> >179  }
> >180
> >181  SBDebugger
> >182  SBDebugger::Create(bool source_init_files, lldb::LogOutputCallback
> callback, void *baton)
> >183
> >
> > Finally, I try to list based on the address of the function:
> > (lldb) list 0x114720
> > error: address resolves to lldb[0x00114720], but there is no line
> table information available for this address.
> >
> > But there is line table information for 0x114720 (from llvm-dwarfdump):
> > 0x00114720177  0 80   0 0  is_stmt
> > 0x00114730178 32 80   0 0  is_stmt 
> > prologue_end
> > 0x00114734178 12 80   0 0
> > 0x00114754178  5 80   0 0
> >
> 

[lldb-dev] unaligned cast in TCPSocket::Connect

2016-10-13 Thread Ted Woodward via lldb-dev
TCPSocket::Connect has this line:

host_str = ::inet_ntoa (*(struct in_addr
*)*host_entry->h_addr_list);

 

host_entry->h_addr_list is a char**, while struct in_addr contains a
uint32_t. Casting like this (char * to uint_32t *) could cause a bus error
on systems that don't allow non-aligned loads. I think we need to memcpy the
data into a struct in_addr variable.

 

Anyone have any thoughts on this?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


Re: [lldb-dev] Problem with watchpoints

2016-09-15 Thread Ted Woodward via lldb-dev
>> 
> Good point about licensing.  That said, if the concern is duplicating 
> the implementation, I doubt that I could do it if I tried :)
> 
> Duplication of the API should not be an issue either as I plan to 
> strictly adhere to the existing SB api.
> 

That sounds right.

Jim


>> Jim
>> 
>> 
>>> 
>>> \author{Dan}
>>> 
>>> On Fri, Sep 9, 2016 at 3:52 PM, Jim Ingham <jing...@apple.com> wrote:
>>> The main problem with the watchpoint code is that it doesn't share nearly 
>>> as much of the implementation of options and callback handling with the 
>>> breakpoints as it should.  For instance, there's very little need for 
>>> WatchpointOptions and BreakpointOptions to be separate classes, they do 
>>> pretty much exactly the same thing.  If you want to hack on this, the best 
>>> approach I think would be to remove the watchpoint options, and see how far 
>>> you can get using the breakpoint option class.  I bet a lot of goodness 
>>> will fall out of that.  The PerformActions for the StopInfoWatchpoint and 
>>> StopInfoBreakpoint could probably share much of their implementations as 
>>> well.  This is one of those cleanups that's been floating around on all our 
>>> to-do lists for a while now, but keeps getting displaced by other tasks.
>>> 
>>> The BreakpointOptions.h and WatchpointOptions.h files a pretty well 
>>> documented.  That's a fairly good example of how we used to do this.  We 
>>> don't tend to put top-level docs in .cpp files.
>>> 
>>> Jim
>>> 
>>> 
>>>> On Sep 9, 2016, at 2:13 PM, Daniel Noland via lldb-dev 
>>>> <lldb-dev@lists.llvm.org> wrote:
>>>> 
>>>> I have also noticed a few problems similar to Ted's and I plan to 
>>>> address them assuming nobody else is already on it.  That said, I 
>>>> am new around here so please bear with me :)
>>>> 
>>>> In fact, I have been hacking on a few watchpoint methods for a 
>>>> while now.  I have implemented some features I personally wanted 
>>>> (specifically callback functions in the SBWatchpoint api).
>>>> 
>>>> I have not yet created a PR (or whatever SVN equivalent) for 
>>>> several reasons (obviously including the big reformat), but mostly 
>>>> I am a bit lost with respect to proper procedure here.  I have gone 
>>>> through the code guidelines for LLVM and LLDB, but I am confused about 
>>>> some things.
>>>> 
>>>> * I have written unit test logic, but I don't really understand the 
>>>> LLDB testing framework.  Also, I understand from other threads that 
>>>> the framework is currently in flux in any case.
>>>> 
>>>> * I have written documentation, but I don't know if what I have 
>>>> written is even desirable.  For instance, the corresponding 
>>>> breakpoint implementation is almost totally lacking in source doc.
>>>> 
>>>> * I will need to rebase this patch on the reformatted code.  That 
>>>> is no big deal, but I have little experience with SVN and I will 
>>>> need to do some research to avoid turning an eventual merge into a big 
>>>> chore.
>>>> 
>>>> * I am pretty unclear on the appropriate way to make my changes 
>>>> work with the Python API.  Should that be on a different PR?  Are 
>>>> we targeting Python 2.7 and 3.{4,5} on all platforms?
>>>> 
>>>> * Do I need to check that the test suite passes on other platforms, 
>>>> or will other devs take care of that?  I don't use OSX or Windows.
>>>> 
>>>> Basically, I would like to help, but more than that I want my 
>>>> "help" to be helpful.
>>>> 
>>>> If somebody who knows what is going on would help me out I would 
>>>> greatly appreciate it.
>>>> 
>>>> \author{Daniel Noland}
>>>> 
>>>> On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
>>>>>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev 
>>>>>> <lldb-dev@lists.llvm.org> wrote:
>>>>>> 
>>>>>> I recently discovered a problem with watchpoints talking to the Hexagon 
>>>>>> simulator:
>>>>>> 
>>>>>> (lldb) w s e 0x1000
>>>>>> error: Watchpoint creation failed (addr=0x1000, size=4).
>>>>>> error: Target supports (0) hardware watchpoint slots

Re: [lldb-dev] Python3 compatibility for the API

2016-09-13 Thread Ted Woodward via lldb-dev
I just built lldb on Ubuntu 12 with Python 3.5.1. I needed to set python 
includes, python library and python executable in cmake.

I found a problem with the tests - most ran fine, but I got errors with tests 
that tried to use pexpect, like TestConvenienceVariables.py.
  File 
"/local/scratch/ted/8.1/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
 line 82
except ImportError, e:
  ^
SyntaxError: invalid syntax

If we want to run the tests with Python3 we'll need to update pexpect.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Luke 
Drummond via lldb-dev
Sent: Tuesday, August 30, 2016 7:01 AM
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Python3 compatibility for the API

Hi Zachary, Peter

On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:
> Right, the existing version that is built and what you are using links 
> directly against a 2.7 libpython at compile time.  So you would 
> probably need to build LLDB from source and tweak the build system to 
> make it possible to link against your 3.x version of python.  There's 
> some build instructions on the website 
> .  I know there's a few linux 
> developers around here, so it's possible someone else would be 
> interested in making this work as well, but I don't know that it's on 
> anyone's immediate timeline.

We build lldb against python3 regularly, because - as Zachary said - this is 
the only way to get scripting support on windows. To link against python3 on 
Linux you *should* just need the correct headers installed, and invoke CMake 
with the correct python path. For Ubuntu:

```
sudo apt install python3-dev
cmake "$PATH_TO_LLVM_SRC" -DPYTHON_EXECUTABLE:FILEPATH=$(which python3) ```

*should* give you everything you need. However, you may see that cmake picks up 
the python3 interpreter correctly, but tries to link against the python2.7 
library.

-- Found PythonInterp: /usr/bin/python3 (found version "3.5.2") [...]
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version 
"2.7.12")

This appears to be due to a problem in LLVM's CMakeLists.txt specifying support 
for 2.7 only. I have a patch to fix the issue awaiting review
[here](https://reviews.llvm.org/D20825) which should fix the issue on Linux 
when multiple pythons are installed. It may be worth applying this patch 
locally and see how you get on.

Hope that helps

Best

Luke
___
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] Passing std::atomics by value

2016-08-26 Thread Ted Woodward via lldb-dev

Would the misalignment really be a problem on x86? I thought the core handled 
misaligned loads and stores. Unlike, say, PPC.

Either way, I'd expect the compiler to automatically align a uint64.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim Ingham 
via lldb-dev
Sent: Friday, August 26, 2016 2:32 PM
To: Zachary Turner 
Cc: LLDB 
Subject: Re: [lldb-dev] Passing std::atomics by value

That seems to me a compiler bug, not: "You can't pass structures with 
std::atomic" elements in them by value.  It would crazy to add a type to the 
C++ language that you couldn't use everywhere.  There doesn't seem to be any 
official restriction.  And anecdotally there's a reference to the problem in 
gcc for PPC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259) but that was 
considered a bug and fixed.

Not that it matters much, you are stuck with the compiler you're stuck with, 
bugs and all.

Jim

> On Aug 26, 2016, at 12:26 PM, Zachary Turner  wrote:
> 
> It could, in theory, it just doesn't.  I compiled a quick program using 
> i686-darwin as the target and the generated assembly makes no attempt to pad 
> the arguments.
> 
> I'll post some code later
> 
> On Fri, Aug 26, 2016 at 11:42 AM Jim Ingham  wrote:
> 
> > On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > The thing is, the code is already full of data races.  I think the 
> > std::atomic is actually used incorrectly and is not even doing anything.
> >
> > That said, consider darwin on 32-bit, where I believe each stack frame is 
> > 4-byte aligned.  I dont' think there's any way the compiler can guarantee 
> > that a function parameter is 8-byte aligned without allocating from the 
> > heap, which is obviously impossible for a stack variable.
> 
> Why can't the compiler pad the argument slot on the stack so that the actual 
> struct lives at a properly aligned location?  It's copying the value into the 
> callee's stack frame, so it can put it wherever it wants.  And both caller 
> and callee sites know the alignment requirements from the function signature, 
> so they can both figure out where the actual struct lives in the argument 
> slot based on the alignment of the stack slot.
> 
> Jim
> 
> 
> >
> > On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton  wrote:
> >
> > > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev 
> > >  wrote:
> > >
> > >>
> > >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
> > >>  wrote:
> > >>
> > >> I recently updated to Visual Studio 2015 Update 3, which has improved 
> > >> its diagnostics.  As a result of this, LLDB is uncompilable due to a 
> > >> slew of errors of the following nature:
> > >>
> > >> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
> > >> 'default_stop_addr': formal parameter with requested alignment of 8 
> > >> won't be aligned
> > >>
> > >> The issue comes down to the fact that lldb::Address contains a 
> > >> std::atomic, and is being passed by value pervasively 
> > >> throughout the codebase.  There is no way to guarantee that this value 
> > >> is 8 byte aligned.  This has always been a bug, but until now the 
> > >> compiler just hasn't been reporting it.
> > >>
> > >> Someone correct me if I'm wrong, but I believe this is a problem on any 
> > >> 32-bit platform, and MSVC is just the only one erroring.
> > >>
> > >> I'm not really sure what to do about this.  Passing 
> > >> std::atomic's by value seems wrong to me.
> > >>
> > >> Looking at the code, I don't even know why it needs to be atomic.  It's 
> > >> not even being used safely.  We'll have a single function write the 
> > >> value and later read the value, even though it could have been used in 
> > >> the meantime. Maybe what is really intended is a mutex.  Or maybe it 
> > >> doesn't need to be atomic in the first place.
> > >>
> > >> Does anyone have a suggestion on what to do about this?  I'm currently 
> > >> blocked on this as I can't compile LLDB.
> > >
> > > Feel free to #ifdef around the m_offset member of Address and you can 
> > > have the data race and compile. This seems like a compiler bug to me. If 
> > > a struct/classe by value argument has alignment requirements, then the 
> > > compiler should handle this correctly IMHO. Am I wrong
> >
> > Or if this isn't a compiler bug, feel free to modify anything that was 
> > passing Address by value and make it a "const Address &".
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 


Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

2016-08-26 Thread Ted Woodward via lldb-dev
After the core file is loaded in ProcessElfCore::DoLoadCore, the logic under 
"target create" will merge the ArchSpec of the target and the core, replacing 
the "unknown" OS in the core ArchSpec with "linux" from the target ArchSpec.

Howard, are you loading a target executable, or just the core?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, August 26, 2016 11:08 AM
To: Ted Woodward <ted.woodw...@codeaurora.org>
Cc: Howard Hellyer <hhell...@uk.ibm.com>; Todd Fiala <todd.fi...@gmail.com>; 
LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

It is ok for a core file to not pledge allegiance to an OS, it is ok for the OS 
to be set to "*" or any OS. Linux core files are useless without the main 
executable anyway so these two things should used together to do the right 
thing. When creating the core files you use:

lldb::ProcessSP
ProcessElfCore::CreateInstance (lldb::TargetSP target_sp, lldb::ListenerSP 
listener_sp, const FileSpec *crash_file) {

So you are handed the target. You can get the executable file from the target 
and also check the target's architecture or the main executable's architecture. 
There shouldn't be a problem figuring this out right?

Greg

> On Aug 26, 2016, at 8:17 AM, Ted Woodward via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> That works fine for host debug, but not so much for embedded. On Hexagon, we 
> support 2 OS cases – standalone (which means no OS, or an OS that lldb 
> doesn’t know anything about) and Linux. Both our standalone simulator and our 
> Linux generate core dumps using ELFOSABI_NONE. We run lldb on both x86 Linux 
> and Windows, and our core dumps need to work on both.
>  
> Doesn’t lldb get the correct OS from the target when you load them together?
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>  
> From: Howard Hellyer [mailto:hhell...@uk.ibm.com]
> Sent: Friday, August 26, 2016 8:39 AM
> To: Todd Fiala <todd.fi...@gmail.com>
> Cc: LLDB <lldb-dev@lists.llvm.org>; Ted Woodward 
> <ted.woodw...@codeaurora.org>
> Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
>  
> Todd Fiala <todd.fi...@gmail.com> wrote on 25/08/2016 20:42:31:
> 
> > FWIW, I've taken a few whacks at getting Linux detected better over 
> > the last few years, and haven't yet found a reliable way to detect 
> > it from quite a few samples of cores from a number of different 
> > systems.  We can spend more time looking into it, but that stone has 
> > been turned over several times.
> 
> I spent quite a lot of time looking at the output of readelf too. I was kind 
> of hoping Linux was the only platform not using it's OSABI value, which would 
> have worked. 
> 
> The only other thing I thought of suggesting was having the ELFOSABI_NONE 
> case ifdef'd so that lldb defaults to the platform that it was built for - on 
> the assumption that you are probably opening a core from the machine you are 
> on. (So on Linux ELFOSABI_NONE would mean Linux, on FreeBSD it would mean 
> FreeBSD.) That would have meant lldb behaved differently depending on where 
> it was compiled which seems wrong and would introduce awkward to debug 
> behaviour so I ended up talking myself out of it.
> 
> Howard Hellyer
> IBM Runtime Technologies, IBM Systems
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU ___
> 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] Linux ELF header e_ident[EI_OSABI] value

2016-08-26 Thread Ted Woodward via lldb-dev
That works fine for host debug, but not so much for embedded. On Hexagon, we
support 2 OS cases - standalone (which means no OS, or an OS that lldb
doesn't know anything about) and Linux. Both our standalone simulator and
our Linux generate core dumps using ELFOSABI_NONE. We run lldb on both x86
Linux and Windows, and our core dumps need to work on both.

 

Doesn't lldb get the correct OS from the target when you load them together?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: Howard Hellyer [mailto:hhell...@uk.ibm.com] 
Sent: Friday, August 26, 2016 8:39 AM
To: Todd Fiala 
Cc: LLDB ; Ted Woodward

Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

 

Todd Fiala  > wrote on
25/08/2016 20:42:31:

> FWIW, I've taken a few whacks at getting Linux detected better over 
> the last few years, and haven't yet found a reliable way to detect 
> it from quite a few samples of cores from a number of different 
> systems.  We can spend more time looking into it, but that stone has
> been turned over several times. 

I spent quite a lot of time looking at the output of readelf too. I was kind
of hoping Linux was the only platform not using it's OSABI value, which
would have worked. 

The only other thing I thought of suggesting was having the ELFOSABI_NONE
case ifdef'd so that lldb defaults to the platform that it was built for -
on the assumption that you are probably opening a core from the machine you
are on. (So on Linux ELFOSABI_NONE would mean Linux, on FreeBSD it would
mean FreeBSD.) That would have meant lldb behaved differently depending on
where it was compiled which seems wrong and would introduce awkward to debug
behaviour so I ended up talking myself out of it. 


Howard Hellyer
IBM Runtime Technologies, IBM Systems 







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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


Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

2016-08-22 Thread Ted Woodward via lldb-dev
We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is historically 
ELFOSABI_SYSV, and used by a lot of things. So not all core files identified as 
ELFOSABI_NONE are Linux.  

Whe lldb loads a core file with a target binary, it will merge the 2 triples. 
If it can't identify the OS from the core file, it will use the OS from the 
target file. For example, I just loaded a Hexagon Linux core file, which lldb 
didn't identify as Linux, and a Hexagon Linux target, which lldb did identify 
as Linux. The final triple is correct - hexagon-*-linux:
(lldb) file u:\hexagon-linux\crash -c u:\hexagon-linux\core
Core file 'u:\hexagon-linux\core' (hexagon) was loaded.
(lldb) tar list
Current targets:
* target #0: u:\hexagon-linux\crash ( arch=hexagon-*-linux, 
platform=remote-linux, pid=13818, state=stopped )


ObjectFileELF::RefineModuleDetailsFromNote looks for a note with type NT_FILE, 
then looks in that for a path that starts with "/lib/x86_64-linux-gnu". If it 
finds that, it will set the core file's OS to Linux. Teaching that to speak the 
Linux dialect you're interested in is probably the right way to go.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Monday, August 22, 2016 11:00 AM
To: Howard Hellyer 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value


> On Aug 22, 2016, at 6:00 AM, Howard Hellyer via lldb-dev 
>  wrote:
> 
> I've been trying to understand why some Linux core files fail to load in 
> lldb. 
> 
> The problem seems to be that in the ELF header Linux uses the ELFOSABI_NONE 
> (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either change the 
> e_ident[EI_OSABI] byte to 0x3 in the header or the code in ArchSpec.cpp to 
> treat ELFOSABI_NONE as Linux then LLDB will open these core files perfectly. 
> The Linux core dumps that are being opened successfully seem to be doing so 
> because lldb is using extra optional information in the notes section. Either 
> because it contains notes “owned” by Linux or because of the file names 
> contained in the FILE note type. A lot of core dumps (it appears to be those 
> created by the kernel following a crash rather than gcore) don’t contain the 
> “LINUX” notes and the file paths in the FILE note can vary a lot by Linux 
> distribution. (For example Ubuntu cores work but Redhat cores I've tried 
> don't as the libraries are in different locations.) 
> 
> Linux doesn't seem to use the ELFOSABIT_LINUX value (0x3) but sticks to the 
> ELFOSABI_NONE (0x0) value. This apppears to be true for both executables and 
> core dumps, LLVM was changed to follow this convention (see: 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301607.html 
> ) but lldb still looks for ELFOSABI_LINUX in ELF headers even though 
> executables and core files seem to contain ELFOSABI_NONE in practise. If I 
> compile code with clang the resulting executable uses ELFOSABI_NONE in the 
> e_ident[EI_OSABI] byte. (If I change the byte manually Linux doesn't appear 
> to care. I think it's probably ignoring the byte.) 
> 
> I'd like to submit a patch to change lldb to treat ELF files with 
> ELFOSABI_NONE set as Linux as a) it would allow lldb to open Linux cores 
> reliably and b) it would match how clang treats e_ident[EI_OSABI]. The code 
> to detect whether lldb is opening a Linux core has changed a lot recently and 
> I don't know the history or if any other ELF platforms leave this byte set to 
> 0x0 in which case this would be confusing, though as this value is currently 
> unused it seems safe. 
> 
> Does anyone know of any reason not to change this? If not I'll submit a patch 
> for review. 

I would change it so that the "os" doesn't get set to anything when it detects 
this in the core file. When an OS is not specified, the llvm::Triple will 
return OSUnknown as the enumeration value for the OS _and_ the llvm::StringRef 
value will return an empty string. This is known in LLDB term as a "unspecified 
unknown". This means the triple will be "x86_64-*-". An unspecified 
unknown is a wildcard. Any plugins that are trying to load a core file should 
watch for this and use it accordingly.

So the answer is not "treat ELF files with ELFOSABI_NONE set as Linux", but 
"treat ELF files with ELFOSABI_NONE set as *". Please submit a patch that 
implements this when you get the chance. Let me know if you have any questions.

Greg Clayton

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

2016-08-11 Thread Ted Woodward via lldb-dev
I don’t think we can completely get rid of the lldb coding conventions doc; 
we’ll need this type of thing as long as we use swig:

 

*  enumerations that might end up being in the lldb SB API's should all be 
written like: 

 

typedef enum EnumName

{

eEnumNameFirstValue,

eEnumNameSecondValue,

} EnumName;

   

This redundancy is important because the enumerations that find their way 
through SWIG into Python will show up as lldb.eEnumNameFirstValue, so including 
the enum name in the value name disambiguates them in Python.   
   

 

Some directed questions about this proposal:

-  Will we move to an 80 column limit?

-  Will we move to camel case for variables?

-  Will we stop putting m_ at the front of class ivars and g_ at the 
front of globals?

-  Will we stop using _sp and _up on the end of shared and unique 
pointers?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Thursday, August 11, 2016 1:37 PM
To: Jim Ingham 
Cc: Kate Stone ; LLDB 
Subject: Re: [lldb-dev] LLDB Evolution

 

I was thinking the same thing too.  I figured this was just for the interim.

 

Chris, did you mean to update the global LLVM style conventions?

 

On Thu, Aug 11, 2016 at 11:27 AM Jim Ingham  > wrote:

Shouldn't this be made general and added to the llvm coding conventions?  I was 
assuming that upon completion of this exercise, we would delete the lldb coding 
conventions doc.

Jim

> On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev 
>  > wrote:
>
> On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner   > wrote:
>
>> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev 
>>  > wrote:
>>
>> So perhaps it would be reasonable for us to standardize on something like 
>> this:
>>
>>  • Main Module Header
>>  • Local/Private Headers
>>  • lldb/...
>>  • llvm/...
>>  • System #includes
>
> This makes sense to me, and matches what clang does as well.  I think that 
> this is clearly in the spirit of the llvm include order standards, and I 
> think it would be great to make this explicit in the coding standard doc.  
> Can you send in a patch to update it to make this explicit?  I’ll review it.
>
> -Chris
>
> I actually just submitted the patch.  (Sorry, itchy trigger finger or 
> something).  r278373.  If you have any comments let me know and I'm happy to 
> iterate on it.
>
> ___
> 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] Question about -break-insert in lldb-mi

2016-07-12 Thread Ted Woodward via lldb-dev
It looks like the current implementation expects the -f to be right before the 
break location. So "-break-insert main" or "-break-insert -t -f main -d" would 
work, but "-break-insert -t main -f -d" would not.
It also looks as if restricting the breakpoint to the thread id (incorrectly) 
only works if a condition is set.

From my reading of the spec at 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html , 
-f should not take a parameter.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] 
Sent: Monday, July 11, 2016 3:59 PM
To: Ted Woodward ; jing...@apple.com; 'LLDB' 

Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi

So the instance I run into the error is setting a conditional breakpoint:

-break-insert -f -c "x==0" main.cpp:13

And I get: 

MI: Error: Command Args. Validation failed. Args missing additional 
information: f ^error,msg="Command 'break-insert'. Command Args. Validation 
failed. Args missing additional information: f"

It seems in the tests/examples, -f is the last parameter and the function/code 
location happens after the -f. 

From my understanding of the MI Command, the -f is a flag that tells it the 
breakpoint is to be set as pending if the debugger cannot determine the 
location of the breakpoint. The optional "parameter" doesn't seem to be used. 

Does this seem like a bug or am I misunderstanding what the -f flag does on 
-break-insert ?

Thanks
Pierson 

-Original Message-
From: Ted Woodward [mailto:ted.woodw...@codeaurora.org]
Sent: Monday, July 11, 2016 1:13 PM
To: Pierson Lee (PIE) ; jing...@apple.com; 'LLDB' 

Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi

This is what Eclipse does when setting a breakpoint at main on a Hexagon 
target, before -exec-run:

TX:21-break-insert -t -f main

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pierson 
Lee (PIE) via lldb-dev
Sent: Monday, July 11, 2016 1:33 PM
To: jing...@apple.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi

If I don't specify the -f flag (with some random parameter), then a pending 
breakpoint is not created and the initial binding fails. But if I specify the 
-f with the random parameter, then it will bind when the library is loaded. 
This is the behavior I see on gdb also, but sans the random parameter. I looked 
at the source code and can't figure out what it expects the parameter to be and 
what it does with the value. 

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com]
Sent: Friday, July 8, 2016 7:03 PM
To: Pierson Lee (PIE) 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi


gdb used to try to find a symbol matching the breakpoint specification and if 
it didn't find one immediately, it would raise an error.  If you didn't want 
this behavior (in a world with many shared libraries you seldom did) then you 
could set a "future-break" which is what the -f flag turns on.  This was better 
though a bit bogus, because it would set the breakpoint the FIRST time it took, 
then never look again.

But this was quite a while ago, and I think gdb's gotten better about 
organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
not sure how it works now-a-days.

Anyway, lldb's breakpoints don't work that way.  They stay active till you 
delete them, and keep searching for new matches every time a shared library is 
loaded.  You could make them emulate the gdb behavior by judiciously deleting & 
duplicating breakpoints from the original specification, but there's no way to 
get the native lldb breakpoints to do so (nor should there be IMHO...)

So if you are using the lldb-mi, there's no reason to bother with the -f flag.  
But also lldb-mi should probably just ignore this flag.

Jim
 

> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>  wrote:
> 
> Hi,
>  
> I’m trying to use -break-insert and the -f flag for it. 
>  
> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
> the -f has a required parameter.
>  
> m_setCmdArgs.Add(new 
> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>
> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>  
>  
> Based on the GDB MI documentation (at 
> 

Re: [lldb-dev] LLDB-MI from Eclipse hangs

2016-07-11 Thread Ted Woodward via lldb-dev
I wanted a log with Eclipse talking to lldb-mi to see if it was doing anything 
odd. It's not:

-exec-continue --thread-group i1
<   5> send packet: $c#63
-list-thread-groups i1   



We have lldb-mi launch hexagon-sim automatically; it launches the same way 
debugserver does, with reverse-connect. I'd expect an -exec-run to do this 
automatically for you. No need to specify parameters to debugserver.



Here is some of a log of Eclipse talking to lldb-mi talking to a Hexagon 
target. It looks very similar, except for -exec-run instead of -target-select 
remote and -exec-continue:

TX:21-break-insert -t -f main

RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
TX:22-list-thread-groups

RX:(gdb)
RX:21^done,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="0",original-location="main"}
RX:(gdb)
TX:23-exec-run

RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="0",original-location="main"}
RX:(gdb)
RX:22^done,groups=[{id="i1",type="process",executable="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\hexagon_Debug_toolv80_v60/downscaleBy2_q"}]
RX:(gdb)
RX:23^running
RX:=thread-group-started,id="i1",pid="1"
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1e002f38",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="121",pending=["downscaleBy2.c:110"],times="0",original-location="downscaleBy2.c:110"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x1e002df0",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="96",pending=["downscaleBy2.c:96"],times="0",original-location="downscaleBy2.c:96"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="1",original-location="main"}
TX:24-list-thread-groups --available

RX:(gdb)
RX:=thread-created,id="1",group-id="i1"
RX:=thread-created,id="2",group-id="i1"
RX:=thread-created,id="3",group-id="i1"
RX:=thread-created,id="4",group-id="i1"
RX:=thread-selected,id="1"
RX:(gdb)
RX:23^running
RX:=thread-group-started,id="i1",pid="1"
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1e002f38",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="121",pending=["downscaleBy2.c:110"],times="0",original-location="downscaleBy2.c:110"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x1e002df0",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="96",pending=["downscaleBy2.c:96"],times="0",original-location="downscaleBy2.c:96"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="1",original-location="main"}
TX:24-list-thread-groups --available

RX:(gdb)
RX:=thread-created,id="1",group-id="i1"
RX:=thread-created,id="2",group-id="i1"
RX:=thread-created,id="3",group-id="i1"
RX:=thread-created,id="4",group-id="i1"

Re: [lldb-dev] LLDB-MI from Eclipse hangs

2016-07-08 Thread Ted Woodward via lldb-dev
A few thoughts:

1)  I think lldb-mi now takes lldb commands, so you could do the log in 
your manual copy/paste. The command you want is:

log enable gdb-remote packets

Do it after the stop, before the –break-insert. You’ll get a bunch of data 
after the –break-insert, then do the –exec-continue and –list-thread-groups, 
and send the data that comes out after those.

 

2)  I see from the log that you’re doing a –target-select remote. Are you 
running debugserver manually? What happens if you don’t run debugserver, and 
have Eclipse do –exec-run instead of –target-select remote?

The original Codeplay implementation of lldb-mi talked to the Hexagon 
Simulator, but didn’t have a way to launch it, so they only used –target-select 
remote, and not –exec-run. Debugserver can be launched automatically, so 
–exec-run should work.

 

3)  This is an answer to Greg’s question about –exec-continue and 
–list-thread-groups. I was going to ask the same thing, but I looked over some 
old logs I had. Eclipse called –list-thread-groups while the target was 
running, and it worked fine. This was with a 2 year old lldb-mi, but I’d expect 
a modern lldb-mi to work as well. The spec at 
https://sourceware.org/gdb/onlinedocs/gdb/Thread-groups.html talks about what 
this command does. It gives a list of process groups that the debugger is 
debugging, so it doesn’t matter if a certain process is running or not.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: dipt...@gmail.com [mailto:dipt...@gmail.com] 
Sent: Friday, July 08, 2016 6:23 AM
To: Ted Woodward 
Cc: Greg Clayton ; LLDB 
Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs

 

Thanks Ted for your reply.

I tried the same command that eclipse uses manually from command prompt. It 
hangs after same last command "-exec-continue --thread-group i1". Attached is 
the lldb-mi sample at that time.

 

While debugging from Eclipse I am going to Run--> Debug Configurations--> C/C++ 
Remote Applications-->  and then click on Debug button. And 
then all the commands are executed by Eclipse automatically. I do not see two 
different steps as attach and continue. So I am not sure how to pass command 
"log enable gdb-remote packets". May be I am missing something. Can you please 
help me here, so that I can get the required log as suggested by you? Thanks.

 

 

-- 

Have a nice day!
Regards,
Dipti

On Fri, Jul 8, 2016 at 4:01 AM, Ted Woodward  > wrote:

I don’t see anything in the log that looks like a problem. I’ve got 2 thoughts:

 

1)  Have you tried manual debugging with the same sequence that eclipse 
uses? You can copy/paste lines from the log, just remove some extraneous 
logging info, so

313,464 14-file-exec-and-symbols --thread-group i1 
"/Users/admin/Documents/workspace/Hello World C++\

 Project/Debug/Hello World C++ Project"

Becomes

-file-exec-and-symbols --thread-group i1 
"/Users/admin/Documents/workspace/Hello World C++ Project/Debug/Hello World C++ 
Project"

Copy/paste the exact sequence.

 

2)  A packet log after the –list-thread-groups that hangs would be useful. 
After you attach in eclipse, but before you continue, go to the GDB console tab 
and type:

log enable gdb-remote packets

You should get a line in the log that says

-interpreter-exec console “log enable gdb-remote packets”

and then get a giant spew of data after the continue. Please send that data.

 

I worked on getting lldb-mi working with Eclipse for Hexagon; there were times 
when I’d have to copy/paste what Eclipse sent over to replicate problems, and 
bisect those commands to find the combination that caused my bad behavior. You 
may need to do that here.

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
 ] On Behalf Of via lldb-dev
Sent: Thursday, July 07, 2016 10:53 AM
To: Greg Clayton  >
Cc: lldb-dev@lists.llvm.org  
Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs

 

Thanks Greg for your reply.

 

Attached below is the GDB trace, please let me know if it helps in any ways.

 

It would be helpful if you can tell me on how to capture (I am really new to 
lldb, sorry for bothering you):

- sample lldb-mi to see what it is doing. 

- complete packet log of the traffic between Eclipse and lldb-mi 

 

I am trying with simple "Hello world" c++ program, so libraries should to be a 
problem. Also, same remote debugging is working fine if I manually do it using 
lldb-mi from command prompt. The hang 

Re: [lldb-dev] Discrete code and data memories

2016-05-25 Thread Ted Woodward via lldb-dev
What Tyro is describing is called a "Harvard architecture" - 
https://en.wikipedia.org/wiki/Harvard_architecture . It contrasts with the von 
Neumann architecture used by most machines today.

Hexagon has a unified memory map, but I've worked with other DSPs (Motorola 
DSP56xxx) that have a code bus and 1 or more data busses. 56300 was 24 bit, and 
called them p, x and y memories. 56600 had 24 bit p memory and 16 bit x memory. 
And my product at my previous employer took this idea of memory spaces a bit 
farther, and we could use different spaces to access the same memory in 
different ways. So a debugger attached to a Freescale T4240 processor could 
access an address as physical through the SoC, physical/virtual through the 
e6500 PowerPC core (really 1:1 mapping for "physical"), cacheable/non 
cacheable, code/data (code applies the self-modifying code sequence, used 
primarily for software breakpoints). We could combine these options in 
appropriate ways. The memory access functions took a memory space, address, 
size and count.

To implement this in LLDB, we'd need to have a way to decorate a memory range 
with interesting attributes, and a way to get this info over to the remote 
gdb-server.

Duane Ellis talks about some of the issues with supporting this on the GDB 
mailing list: http://comments.gmane.org/gmane.comp.gdb.devel/36147

This actually came up here 2 years ago - 
http://lists.llvm.org/pipermail/lldb-dev/2014-May/004081.html .

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Wednesday, May 25, 2016 3:57 PM
To: Tyro Software 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Discrete code and data memories

I believe that some of the DSPs we have support for (Hexagon?) has this kind of 
issue. I would speak to Ted Woodward and see if they do anything special for 
this.

Greg Clayton

> On May 25, 2016, at 2:16 AM, Tyro Software via lldb-dev 
>  wrote:
> 
> I'm trying to implement LLDB support for an architecture where code and data 
> stores can be explicitly separated and can even have overlapping addresses 
> (one can think of it as ROM and RAM, with separate access buses). 
> 
> My impression is that LLDB somewhat presumes a hybrid memory map, e.g. the 
> client requests "qMemoryRegionInfo:$PC" for the program counter value but 
> might also do "qMemoryRegionInfo:$SP" for the stack pointer and from the 
> address value alone one can't safely determine which memory type is meant. A 
> similar issue would exist for the X/x commands.
> 
> I apologise for not knowing better terminology to describe this - quite 
> possibly LLDB does cater for it and I haven't understood the description, 
> e.g. there's some way to "adorn" an address or set some context or scope for 
> it through a preceding command?
> 
> Thanks
> /Tyro
> ___
> 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


[lldb-dev] bug in TestMiGdbSetShow.test_lldbmi_gdb_set_target_async_off?

2016-05-18 Thread Ted Woodward via lldb-dev
Packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py, in
test_lldbmi_gdb_set_target_async_off we have this code:

 

self.runCmd("-gdb-set target-async off")

 

.

 

self.runCmd("-exec-run")

unexpected = [ "\*running" ] # "\*running" is async notification

it = self.expect(unexpected + [ "@\"argc=1rn" ])

if it < len(unexpected):

self.fail("unexpected found: %s" % unexpected[it])

 

But lldb-mi does the right thing, expect won't match "running", so the
self.expect command fails, which causes the test to error out. Shouldn't the
self.expect be in a try, with an except being a pass?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-10 Thread Ted Woodward via lldb-dev
  // Be sure to apply and file remappings to our file 
>>> and line
>>>  // entries when handing out a line entry
>>>  FileSpec new_file_spec;
>>>  if (m_sc.target_sp->GetSourcePathMap().FindFile 
>>> (m_sc.line_entry.file, new_file_spec))
>>>  m_sc.line_entry.file = new_file_spec;
>>>  }
>>> 
>>> This code gets called if the StackFrame ctor is called with the 
>>> SymbolContext = nullptr, but this is skipped if the SymbolContext is valid. 
>>> All new StackFrames in StackFrameList are done with a null SC, except for 
>>> an inlined frame. In that case, StackFrameList::GetFramesUpTo calls 
>>> SymbolContext::GetParentOfInlinedScope, which sets the SC, and 
>>> GetFramesUpTo does not remap it like StackFrame::GetSymbolContext does. 
>>> Then it creates a new StackFrame with the SC.
>>> 
>>> Adding this before the new StackFrame fixes the issue:
>>>  if (target_sp)
>>>  {
>>>  // Be sure to apply and file remappings to our file 
>>> and line
>>>  // entries when handing out a line entry
>>>  FileSpec new_file_spec;
>>>  if 
>>> (target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file, 
>>> new_file_spec))
>>>  next_frame_sc.line_entry.file = new_file_spec;
>>>  }
>>> 
>>> I've put up a patch on Phabricator with Jim as reviewer.
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>>> Linux Foundation Collaborative Project
>>> 
>>> 
>>> -Original Message-
>>> From: jing...@apple.com [mailto:jing...@apple.com] 
>>> Sent: Friday, May 06, 2016 2:41 PM
>>> To: Ted Woodward <ted.woodw...@codeaurora.org>
>>> Cc: LLDB <lldb-dev@lists.llvm.org>
>>> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol 
>>> context and target.source-map setting
>>> 
>>> 
>>>> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev 
>>>> <lldb-dev@lists.llvm.org> wrote:
>>>> 
>>>> I’m stepping over the first line of a libcxx test (source 
>>>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>>>>  ). The first line has an inlined function call. I expect lldb to step 
>>>> over the breakpoint, run to the end of the range that sets up the inlined 
>>>> function call, run through the inlined function call, then run to the end 
>>>> of the line. Instead, it runs to the inlined call, then stops.
>>>> 
>>>> I’m running lldb on Windows, debugging a Hexagon application that was 
>>>> built on Linux. I’m using the target.source-map setting to let me see 
>>>> source.
>>>> 
>>>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
>>>> still on the same line by comparing the filename in the Stepping Plan’s 
>>>> line entry to the filename in the current frame’s line entry. 
>>>> m_addr_context.line_entry.file has been normalized by the value in 
>>>> target.source-map, but new_context.line_entry.file hasn’t, so they’re not 
>>>> the same, even though they should be.
>>>> 
>>>>  SymbolContext 
>>>> new_context(frame->GetSymbolContext(eSymbolContextEverything));
>>>>  if (m_addr_context.line_entry.IsValid() && 
>>>> new_context.line_entry.IsValid())
>>>>  {
>>>>  if (m_addr_context.line_entry.file == new_context.line_entry.file)
>>>>  {
>>>> 
>>>> 
>>>> Either both should use target.source-map, or neither should.  How do I run 
>>>> new_context.line_entry.file through the target.source-map normalization?
>>> 
>>> 
>>> 
>>> It doesn't seem right to me that when symbols are handed out they have the 
>>> source map applied to their file spec's.  After all, then you could get 
>>> into problems like: somebody started a step so we recorded m_addr_context.  
>>> Then their step was interrupted (say by hitting a breakpoint) and the user 
>>> added a source mapping.  Then we 

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-09 Thread Ted Woodward via lldb-dev
with Jim as reviewer.
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>> 
>> 
>> -Original Message-
>> From: jing...@apple.com [mailto:jing...@apple.com] 
>> Sent: Friday, May 06, 2016 2:41 PM
>> To: Ted Woodward <ted.woodw...@codeaurora.org>
>> Cc: LLDB <lldb-dev@lists.llvm.org>
>> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol 
>> context and target.source-map setting
>> 
>> 
>>> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev 
>>> <lldb-dev@lists.llvm.org> wrote:
>>> 
>>> I’m stepping over the first line of a libcxx test (source 
>>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>>>  ). The first line has an inlined function call. I expect lldb to step over 
>>> the breakpoint, run to the end of the range that sets up the inlined 
>>> function call, run through the inlined function call, then run to the end 
>>> of the line. Instead, it runs to the inlined call, then stops.
>>> 
>>> I’m running lldb on Windows, debugging a Hexagon application that was built 
>>> on Linux. I’m using the target.source-map setting to let me see source.
>>> 
>>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
>>> still on the same line by comparing the filename in the Stepping Plan’s 
>>> line entry to the filename in the current frame’s line entry. 
>>> m_addr_context.line_entry.file has been normalized by the value in 
>>> target.source-map, but new_context.line_entry.file hasn’t, so they’re not 
>>> the same, even though they should be.
>>> 
>>>   SymbolContext 
>>> new_context(frame->GetSymbolContext(eSymbolContextEverything));
>>>   if (m_addr_context.line_entry.IsValid() && 
>>> new_context.line_entry.IsValid())
>>>   {
>>>   if (m_addr_context.line_entry.file == new_context.line_entry.file)
>>>   {
>>> 
>>> 
>>> Either both should use target.source-map, or neither should.  How do I run 
>>> new_context.line_entry.file through the target.source-map normalization?
>> 
>> 
>> 
>> It doesn't seem right to me that when symbols are handed out they have the 
>> source map applied to their file spec's.  After all, then you could get into 
>> problems like: somebody started a step so we recorded m_addr_context.  Then 
>> their step was interrupted (say by hitting a breakpoint) and the user added 
>> a source mapping.  Then we stop in a frame from the same module, and now the 
>> SymbolContext that the step plan stored (m_addr_context) has a different 
>> path than the one in the frame when we get to it.  Checking every time you 
>> compared file specs seems very error prone, we shouldn't do it that way.  I 
>> guess if the FileSpec == handled this it would be odd but not too bad.  But 
>> that seems like it would result in a lot of unnecessary work.  I think it 
>> would be better to only do source map path conversion when sources are 
>> looked up, and maybe when paths are printed.  For symbols we should stick to 
>> what the debug info says.
>> 
>> Jim
>> 
>> 
>>> 
>>> Ted
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>>> Linux Foundation Collaborative Project
>>> 
>>> ___
>>> 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] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-06 Thread Ted Woodward via lldb-dev
Symbols are being remapped. StackFrame::GetSymbolContext does this:

m_sc.line_entry = sc.line_entry;
if (m_sc.target_sp)
{
// Be sure to apply and file remappings to our file and 
line
// entries when handing out a line entry
FileSpec new_file_spec;
if (m_sc.target_sp->GetSourcePathMap().FindFile 
(m_sc.line_entry.file, new_file_spec))
m_sc.line_entry.file = new_file_spec;
}

This code gets called if the StackFrame ctor is called with the SymbolContext = 
nullptr, but this is skipped if the SymbolContext is valid. All new StackFrames 
in StackFrameList are done with a null SC, except for an inlined frame. In that 
case, StackFrameList::GetFramesUpTo calls 
SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo 
does not remap it like StackFrame::GetSymbolContext does. Then it creates a new 
StackFrame with the SC.

Adding this before the new StackFrame fixes the issue:
if (target_sp)
{
// Be sure to apply and file remappings to our file and 
line
// entries when handing out a line entry
FileSpec new_file_spec;
if 
(target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file, 
new_file_spec))
next_frame_sc.line_entry.file = new_file_spec;
}

I've put up a patch on Phabricator with Jim as reviewer.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com] 
Sent: Friday, May 06, 2016 2:41 PM
To: Ted Woodward <ted.woodw...@codeaurora.org>
Cc: LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context 
and target.source-map setting


> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> I’m stepping over the first line of a libcxx test (source 
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>  ). The first line has an inlined function call. I expect lldb to step over 
> the breakpoint, run to the end of the range that sets up the inlined function 
> call, run through the inlined function call, then run to the end of the line. 
> Instead, it runs to the inlined call, then stops.
>  
> I’m running lldb on Windows, debugging a Hexagon application that was built 
> on Linux. I’m using the target.source-map setting to let me see source.
>  
> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
> still on the same line by comparing the filename in the Stepping Plan’s line 
> entry to the filename in the current frame’s line entry. 
> m_addr_context.line_entry.file has been normalized by the value in 
> target.source-map, but new_context.line_entry.file hasn’t, so they’re not the 
> same, even though they should be.
>  
> SymbolContext 
> new_context(frame->GetSymbolContext(eSymbolContextEverything));
> if (m_addr_context.line_entry.IsValid() && 
> new_context.line_entry.IsValid())
> {
> if (m_addr_context.line_entry.file == new_context.line_entry.file)
> {
>  
>  
> Either both should use target.source-map, or neither should.  How do I run 
> new_context.line_entry.file through the target.source-map normalization?



It doesn't seem right to me that when symbols are handed out they have the 
source map applied to their file spec's.  After all, then you could get into 
problems like: somebody started a step so we recorded m_addr_context.  Then 
their step was interrupted (say by hitting a breakpoint) and the user added a 
source mapping.  Then we stop in a frame from the same module, and now the 
SymbolContext that the step plan stored (m_addr_context) has a different path 
than the one in the frame when we get to it.  Checking every time you compared 
file specs seems very error prone, we shouldn't do it that way.  I guess if the 
FileSpec == handled this it would be odd but not too bad.  But that seems like 
it would result in a lot of unnecessary work.  I think it would be better to 
only do source map path conversion when sources are looked up, and maybe when 
paths are printed.  For symbols we should stick to what the debug info says.

Jim


>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> 

[lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-06 Thread Ted Woodward via lldb-dev
I'm stepping over the first line of a libcxx test (source
https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit
ion/thread.condition.condvar/wait.pass.cpp ). The first line has an inlined
function call. I expect lldb to step over the breakpoint, run to the end of
the range that sets up the inlined function call, run through the inlined
function call, then run to the end of the line. Instead, it runs to the
inlined call, then stops.

 

I'm running lldb on Windows, debugging a Hexagon application that was built
on Linux. I'm using the target.source-map setting to let me see source.

 

The problem is in ThreadPlanStepRange::InRange. It checks to see if we're
still on the same line by comparing the filename in the Stepping Plan's line
entry to the filename in the current frame's line entry.
m_addr_context.line_entry.file has been normalized by the value in
target.source-map, but new_context.line_entry.file hasn't, so they're not
the same, even though they should be.

 

SymbolContext
new_context(frame->GetSymbolContext(eSymbolContextEverything));

if (m_addr_context.line_entry.IsValid() &&
new_context.line_entry.IsValid())

{

if (m_addr_context.line_entry.file ==
new_context.line_entry.file)

{

 

 

Either both should use target.source-map, or neither should.  How do I run
new_context.line_entry.file through the target.source-map normalization?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


[lldb-dev] odd behavior when source stepping libcxx test - lldb thinks process is running, but never sent a step/resume

2016-04-22 Thread Ted Woodward via lldb-dev
We're porting libcxx to Hexagon. Stepping the first line in wait.pass.cpp
will put lldb in a bad state - it thinks the target has resumed, but it
never sends a step or resume packet to the remote gdbserver. Sometimes it
will step part of the line, return control, then stepping again goes to the
bad state.

 

The system has 4 threads; only thread 3 is currently being used. The bad
state happens because ProcessGDBRemote::DoResume can't figure out how to
send a resume packet. During the thread plan it resumes all threads. Later
it goes to step thread 3, but it also wants to resume threads 1,2,4, but our
gdbserver doesn't support vCont, so it gives up. I don't think it should be
resuming threads 1,2,4.

 

How can I fix this?

 

The source file is wait.pass.cpp:
https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit
ion/thread.condition.condvar/wait.pass.cpp

 

Disassembly of line 43:

   42   {

-> 43   std::unique_locklk(mut);

   44   std::thread t(f);

->  0x10011c4 <+20>:   { memw(r30+#-20) = r2 }

0x10011c8 <+24>:   { immext(#18198784)

0x10011cc <+28>: r2 = ##18198784 }

0x10011d0 <+32>:   { memw(r30+#-24) = r2 }

0x10011d4 <+36>:   { r2 = memw(r30 + #-20) }

wait.pass.cpp.exe`main + 40 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) at
wait.pass.cpp:43

0x10011d8 <+40>:   { r3 = memw(r30 + #-24) }

wait.pass.cpp.exe`main + 44 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) + 4 at
wait.pass.cpp:43

0x10011dc <+44>:   { memw(r2+#0) = r3 }

wait.pass.cpp.exe`main + 48 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) + 8 at
wait.pass.cpp:43

0x10011e0 <+48>:   { memb(r2+#4)=#1 }

wait.pass.cpp.exe`main + 52 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) + 12
at wait.pass.cpp:43

0x10011e4 <+52>:   { r0 = memw(r2 + #0) }

0x10011e8 <+56>:   { call 0x1001ab4 }; std::__1::mutex::lock at
mutex.cpp:31

 

The only change-of-flow is the call instruction at the end.

 

 

Select linetable info, from llvm-dwarfdump:

AddressLine   Column File   ISA Discriminator Flags

-- -- -- -- --- - -

0x010011c4 43 33 11   0 0  is_stmt
prologue_end

0x010011d8112 17  3   0 0  is_stmt

0x010011dc112 11  3   0 0 

0x010011e0112 23  3   0 0 

0x010011e4112 38  3   0 0 

0x010011ec 44 17 11   0 0  is_stmt

 

File 11 is wait.pass.cpp; file 3 is __mutex_base, where the inlined
std::unique_lock is defined.

 

Step log:

 

(lldb) r

Process 1 launched: 'c:\lldb\test\cxx11\wait.pass.cpp.exe' (hexagon)

Process 1 stopped

* thread #3: tid = 0x0003, 0x010011c4 wait.pass.cpp.exe`main + 20 at
wait.pass.cpp:43, stop reason = breakpoint 1.1

frame #0: 0x010011c4 wait.pass.cpp.exe`main + 20 at wait.pass.cpp:43

   40

   41   int main()

   42   {

-> 43   std::unique_locklk(mut);

   44   std::thread t(f);

   45   assert(test1 == 0);

   46   while (test1 == 0) {

(lldb) thread list

Process 1 stopped

  thread #1: tid = 0x0001, 0xff004f64

  thread #2: tid = 0x0002, 0xff004f64

* thread #3: tid = 0x0003, 0x010011c4 wait.pass.cpp.exe`main + 20 at
wait.pass.cpp:43, stop reason = breakpoint 1.1

  thread #4: tid = 0x0004, 0xff004f64

(lldb) log enable lldb step

(lldb) s

Finding branch index from address @ 0x010011c4

Instruction @0x010011C4 : 0xA79EE2FB

 

Packet start @0x010011C8

 

Instruction @0x010011C8 : 0x001156C4

 

Instruction @0x010011D0 : 0xA79EE2FA

 

Packet start @0x010011D4

 

Thread::PushPlan(0x04E678D0): "Stepping in through line
wait.pass.cpp:43.", tid = 0x0003.

Process::PrivateResume() m_stop_id = 2, public state: stopped private state:
stopped

Failed to create new thread notification breakpoint.

Thread::PushPlan(0x04E678D0): "Single stepping past breakpoint site
2 at 0x10011c4", tid = 0x0003.

lldb_private::ThreadPlan::WillResume Thread #1 (0x045DDE10): tid =
0x0001, pc = 0xff004f64, sp = 0xff00cb78, fp = 0xff002d10, plan = 'base
plan', state= suspended, stop others = 0

lldb_private::ThreadPlan::WillResume Thread #2 (0x04E660B0): tid =
0x0002, pc = 0xff004f64, sp = 0xff00cc70, fp = 0x, plan = 'base
plan', state= suspended, stop others = 0

lldb_private::ThreadPlan::WillResume Thread #3 (0x04E678D0): tid =
0x0003, pc = 0x010011c4, sp = 0x0525eca8, fp = 0x0525ecf8, plan = 'Step over
breakpoint trap', state = stepping, stop others = 1

lldb_private::ThreadPlan::WillResume Thread #4 (0x04E69080): tid =
0x0004, pc = 0xff004f64, sp = 0xff00ce60, fp = 0x, plan = 'base
plan', state= suspended, stop others = 0

Current Plan for thread 1(045DDE10) (0x0001, suspended): base plan
being asked whether we should report run.

Current Plan for 

Re: [lldb-dev] Review of API and remote packets

2016-04-11 Thread Ted Woodward via lldb-dev
I used to work on debug software at Freescale (NXP?), and we had a PPC core 
called e6500. It had 8 IACs (Instruction Address Comparators) that could be 
hooked up to the trace logic in various ways, but one really useful thing you 
could do was set up an IAC to turn on or off trace on a given address or 
address range. So we implemented tracepoints, which were like breakpoints but 
would turn on/off trace. I'd like to see that kind of support in a trace API.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel 
Labath via lldb-dev
Sent: Monday, April 11, 2016 9:51 AM
To: Ravitheja Addepally 
Cc: LLDB 
Subject: Re: [lldb-dev] Review of API and remote packets

I think we should reuse packets from the gdb protocol whereever it makes sense. 
So, if they fit your needs (and a quick glance seems to confirm that), then I 
think you should use them.

On 11 April 2016 at 15:28, Ravitheja Addepally  wrote:
> Hello,
>Regarding the packet definitions for tracing, how about reusing 
> the existing btrace packets ?
>
> https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#q
> Xfer%20btrace%20read
>
> On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton  wrote:
>>
>> We also need to think about all other types of tracing. It might make 
>> more sense to keep these calls on SBProcess and have the calls simply be:
>>
>>
>> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions 
>> _options, lldb::SBError );
>>
>> And you would need to specify which threads in the SBTraceOptions 
>> object
>> itself?:
>>
>> SBTraceOptions trace_options;
>>
>> And then do some like:
>>
>> trace_options.SetTraceAllThreads();
>>
>> And maybe tracing all threads is the default. Or one can limit this 
>> to one
>> thread:
>>
>> trace_options.SetThreadID (tid);
>>
>> Then you start tracing using the "trace_options" which has the notion 
>> of which threads to trace.
>>
>> lldb::SBError error;
>> lldb::SBTrace trace = process.StartTrace(trace_options, error);
>>
>> It really depends on how all different forms of trace are enabled for 
>> different kinds of tracing. It takes kernel support to trace only 
>> specific threads, but someone might be debugging a bare board that 
>> only has the option tracing all threads on each core. When making an 
>> API we can't assume we can limit this to any threads and even to any process.
>>
>> Greg
>>
>> > On Apr 1, 2016, at 2:00 AM, Pavel Labath  wrote:
>> >
>> > I second Greg's suggestions, and I have some thoughts of my own:
>> >
>> > - with the proposed API, it is not possible to get a trace for 
>> > newly created threads - the process needs to be stopped first, so 
>> > you can enable trace collection. There certainly are cases where 
>> > this could be problematic, e.g. if you get a crash early during 
>> > thread creation and you want to figure out how you got there. For 
>> > this to work, we might need an API like
>> > SBProcess::TraceNewThreads(...)
>> > or
>> > SBProcess::TraceAllThreads(...)
>> > with the assumption that "all" also includes newly created threads 
>> > in the future.
>> >
>> > I'm not saying this needs to be done in the first implementation, 
>> > but I think that we should at least design the API in a way that 
>> > will not make adding this unnecessarily hard in the future (e.g. 
>> > the idea of returning an SBTrace object might be problematic, since 
>> > you don't know if/how many threads will be created).
>> >
>> >
>> >
>> > Also, thinking about new APIs, should we have a way to mark an API 
>> > as incubating/experimental? Maybe it would be good to mark these 
>> > new APIs as experimental for a while, so we have an option of 
>> > changing them in the future, if it turns out we have made the wrong 
>> > decision. I was thinking of either a naming convention
>> > (SBThread::StartTraceExperimental) or some annotation/comment on 
>> > the methods. When we are confident this design is good, we can 
>> > remove the promote the api into the "stable" set.
>> >
>> > pl
>> >
>> >
>> >
>> >
>> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev 
>> >  wrote:
>> >>
>> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev 
>> >>>  wrote:
>> >>>
>> >>> Hello all,
>> >>>  I am currently working on enabling Intel (R) 
>> >>> Processor Trace collection for lldb. I have done some previous 
>> >>> discussions in this mailing list on this topic but just to 
>> >>> summarize , the path we chose was to implement raw trace 
>> >>> collection in lldb and the trace will be decoded outside LLDB. I 
>> >>> wanted to expose this feature through the SB API's  and for trace 
>> >>> data transfer I 

[lldb-dev] Get address for PIE-like "process"

2016-04-05 Thread Ted Woodward via lldb-dev
We've got an OS that implements something they call a "user PD", which is a
lot like a PIE process. To debug it, we need to get the address of the image
and then slide the target's symbols. What's the best way to get the address
from the remote stub? Linux lldb reads an AuxVector from lldb-server, but
all we need is an address. I was thinking of using qShlibInfoAddr, but
that's used to get the address of the link map. Is it ok to use that in the
Hexagon DYLD plugin, or is there a better way to get the data from the stub?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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


  1   2   >