date:20161202

[lldb-dev] GDB Remote target descriptions

2016-12-02 Thread jw4...@gmail.com via lldb-dev

Hi all,

I've been adding support for the qXfer:features:read:target.xml message for
our tools at $WORK and have run into a couple hiccups to puzzle over.
First off, the request message as defined at
https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%20description%20read
is in the form qXfer:features:read:annex:offset,size.  When talking to GDB
it works to respond with a 'l' or 'm' message smaller than size, then GDB
proceeds to request the next chunk, and so on until the debug server says
there is no more data.  I believe there is a bug in lldb's handling of this
message in that if the response is shorter than 'size' while also being
incomplete, lldb requests the next chunk with a giant offset.  This patch
fixes the behavior:

Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
(revision 288181)
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
(working copy)
@@ -3342,7 +3342,7 @@
 case ('m'):
   if (str.length() > 1)
 output << [1];
-  offset += size;
+  offset += str.length() - 1;
   break;

 // unknown chunk

Secondly, it appears that lldb only processes a single  element
per "file" when discovering the register descriptions, the workaround seems
to be to put each individual feature in an  file or
conglomerate everything under a single feature in target.xml, but that has
an unfortunate side effect of not working right when talking to GDB.  This
one I didn't dig too far into that code but it looks like
ProcessGDBRemote::GetGDBServerRegisterInfo only extracts a single 
node (the last one) from the target description.

In any case, these are both able to be worked around in my environment
without too much work but it would be nice to get at least that first item
fixed.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Conditionally adding sources to the build

2016-12-02 Thread Pavel Labath via lldb-dev

I am glad to see freebsd is making progress on this front. If you need any
help with understanding how lldb-server works, feel free to shoot me a
question.

pl

On 1 December 2016 at 23:00, Dmitry Mikulin  wrote:

> Thanks for the suggestions.
> I’m working on native support for FreeBSD lldb-server, and wanted to have
> an option to build it both ways until it’s stable enough to replace current
> implementation. I’ll have it in a separate directory.
>
>
> On Dec 1, 2016, at 2:55 AM, Pavel Labath  wrote:
>
> The way we have done this with Linux native register contexts was to
> notionally leave the files in the build, but completely #ifdef out their
> contents (see NativeRegisterConextLinux_arm.cpp).
> It's not very nice, but I think it's better than having six subfolders,
> each with a single cpp file. If you'll need to group more than one file
> this way, then maybe a subfolder would make more sense though.
>
> pl
>
> On 1 December 2016 at 00:30, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Unfortunately you will need to separate them at the directory levels.
>>
>> On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I’m trying to conditionally add source files to the lldb build based on
>>> a cmake configure time variable. I get the following type of errors for all
>>> sources not included in the build:
>>>
>>> CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message):
>>>   Found unknown source file
>>>   /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/
>>> Plugins/Process/FreeBSD/FreeBSDThread.cpp
>>>
>>>   Please update
>>>   /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/
>>> Plugins/Process/FreeBSD/CMakeLists.txt
>>>
>>> Is there a way to work around/fix it or do I need to separate the files
>>> at the directory level?
>>>
>>> Thanks.
>>> Dmitry.
>>>
>>> ___
>>> 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 31245] New: Assertion failed: (m_base_dwarf_cu->GetOffset() == die_ref.cu_offset), function GetDIE, file src/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp, line 120

2016-12-02 Thread via lldb-dev

https://llvm.org/bugs/show_bug.cgi?id=31245

Bug ID: 31245
   Summary: Assertion failed: (m_base_dwarf_cu->GetOffset() ==
die_ref.cu_offset), function GetDIE, file
src/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolF
ileDWARFDwo.cpp, line 120
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: richard-l...@metafoo.co.uk
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Was debugging clang trunk with lldb trunk, when...

(lldb) f 5
frame #5: clang`clang::canCalleeThrow(S=0x093e3bf0,
E=0x09418930, D=0x093ed2b8) at SemaExceptionSpec.cpp:968
   965  T = Op->getRHS()->getType()
   966->castAs()->getPointeeType();
   967} else {
-> 968  T = cast(E)->getMemberDecl()->getType();
   969}
   970  }
   971} else if (const ValueDecl *VD = dyn_cast_or_null(D))
(lldb) p E->dump()
Assertion failed: (m_base_dwarf_cu->GetOffset() == die_ref.cu_offset), function
GetDIE, file
src/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp, line 120
backtrace leading to the failure:
#0 0x7f01f1ed0b68 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
src/lib/Support/Unix/Signals.inc:402:13
#1 0x7f01f009cfca lldb_private::lldb_assert(bool, char const*, char const*,
char const*, unsigned int) src/tools/lldb/source/Utility/LLDBAssert.cpp:30:5
#2 0x7f01f00e384d SymbolFileDWARFDwo::GetDIE(DIERef const&)
src/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp:121:10
#3 0x7f01f00d3b65
SymbolFileDWARF::CompleteType(lldb_private::CompilerType&)
src/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1408:24
#4 0x7f01f002179e
lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)
src/tools/lldb/source/Symbol/Type.cpp:563:7
#5 0x7f01f00217f3 lldb_private::CompilerType::IsValid() const
src/tools/lldb/include/lldb/Symbol/CompilerType.h:75:40
#6 0x7f01f00217f3
lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)
src/tools/lldb/source/Symbol/Type.cpp:584:0
#7 0x7f01f0021967
lldb_private::CompilerType::CompilerType(lldb_private::CompilerType const&)
src/tools/lldb/include/lldb/Symbol/CompilerType.h:45:20
#8 0x7f01f0021967 lldb_private::Type::GetFullCompilerType()
src/tools/lldb/source/Symbol/Type.cpp:597:0
#9 0x7f01f0263834 lldb_private::CompilerType::operator bool() const
src/tools/lldb/include/lldb/Symbol/CompilerType.h:66:19
#10 0x7f01f0263834
lldb_private::ClangExpressionDeclMap::GetVariableValue(std::__1::shared_ptr&,
lldb_private::Value&, lldb_private::TaggedASTType<1u>*,
lldb_private::TaggedASTType<0u>*)
src/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1612:0
#11 0x7f01f02627e0
lldb_private::ClangExpressionDeclMap::AddOneVariable(lldb_private::NameSearchContext&,
std::__1::shared_ptr,
lldb_private::SharingPtr, unsigned int)
src/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1708:7
#12 0x7f01f025fc5c
lldb_private::SharingPtr::~SharingPtr()
src/tools/lldb/include/lldb/Utility/SharingPtr.h:218:7
#13 0x7f01f025fc5c
lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&,
std::__1::shared_ptr, lldb_private::CompilerDeclContext&,
unsigned int)
src/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1223:0
#14 0x7f01f025f07a
lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&)
src/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:814:5
#15 0x7f01f024a24d
lldb_private::ClangASTSource::FindExternalVisibleDeclsByName(clang::DeclContext
const*, clang::DeclarationName)
src/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:175:44
#16 0x7f01f03cb1cc clang::DeclContext::lookup(clang::DeclarationName) const
src/tools/clang/lib/AST/DeclBase.cpp:1486:60
[...]
#65 0x004032b9 _start (stage2/bin/lldb-4.0.0+0x4032b9)
please file a bug report against lldb reporting this failure log, and as many
details as possible
CXXMemberCallExpr 0x9418930 'void'
`-MemberExpr 0x94188f8 '' .g 0x93ed2b8
  `-CXXTemporaryObjectExpr 0x94187d8 'struct dr1330::A' 'void (void) noexcept'
zeroing


Despite the assertion failure, lldb correctly executed the command, and further
executions of the same command work fine ¯\_(ツ)_/¯

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

Re: [lldb-dev] Conditionally adding sources to the build

2016-12-02 Thread Dmitry Mikulin via lldb-dev

I have a slightly unrelated question: is there an easy way to cross-build, say,
an ARM lldb, and run native tests on an ARM board same as what check-lldb does?
The lldb test page only talks about running remote tests. No info on cross
testing.

Thanks!

On Dec 2, 2016, at 2:29 AM, Pavel Labath
> wrote:

I am glad to see freebsd is making progress on this front. If you need any help
with understanding how lldb-server works, feel free to shoot me a question.

On 1 December 2016 at 23:00, Dmitry Mikulin
> wrote:
Thanks for the suggestions.
I’m working on native support for FreeBSD lldb-server, and wanted to have an
option to build it both ways until it’s stable enough to replace current
implementation. I’ll have it in a separate directory.

On Dec 1, 2016, at 2:55 AM, Pavel Labath
> wrote:

The way we have done this with Linux native register contexts was to notionally
leave the files in the build, but completely #ifdef out their contents (see
NativeRegisterConextLinux_arm.cpp).
It's not very nice, but I think it's better than having six subfolders, each
with a single cpp file. If you'll need to group more than one file this way,
then maybe a subfolder would make more sense though.

On 1 December 2016 at 00:30, Zachary Turner via lldb-dev
> wrote:
Unfortunately you will need to separate them at the directory levels.

On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev
> wrote:
Hi,

I’m trying to conditionally add source files to the lldb build based on a cmake
configure time variable. I get the following type of errors for all sources not
included in the build:

CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message):
Found unknown source file

/homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp

Please update

/homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/CMakeLists.txt

Is there a way to work around/fix it or do I need to separate the files at the
directory level?

Thanks.
Dmitry.

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

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

2016-12-02 Thread Stephane Sezer via lldb-dev

Yeah, we have to fake the numbers, we have some sort of dummy mapping
that converts Windows events to the UNIX equivalent that makes the
most sense. It's kind of dumb, but that's the only thing that LLDB or
gdb support.

First half of the conversion is here:
https://github.com/facebook/ds2/blob/master/Sources/Target/Windows/Thread.cpp#L110
and the second half is here:
https://github.com/facebook/ds2/blob/master/Sources/GDBRemote/Structures.cpp#L357

On Thu, Dec 1, 2016 at 3:00 AM, Pavel Labath  wrote:
> I'm curious, can you share how did you deal with the fact that the
> gdb-remote protocol is very signal-centric? E.g. every stop-reply ($T) has
> to have a specific signal associated with it, and some signals have special
> meaning in lldb. Do you just fake the signal numbers when you need to? Or is
> the situation not as bad as I imagine?
>
> cheers,
> pl
>
> On 1 December 2016 at 07:57, Stephane Sezer via lldb-dev
>  wrote:
>>
>> For what it's worth, we've been using lldb with ds2 to do remote
>> debugging on Windows (x86) and Windows Phone (arm) and the lldb side
>> of things works well with remote Windows targets. Besides porting
>> lldb-server to Windows there shouldn't be any extra effort on the lldb
>> side to do what Greg is talking about.
>>
>> On Wed, Nov 30, 2016 at 9:35 AM, Greg Clayton via lldb-dev
>>  wrote:
>> >
>> >> On Nov 29, 2016, at 10:16 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> What would it take to make it so that local and remote process plugins
>> >> use the same exact interface?  I mean in theory they're doing the same
>> >> thing, just on a different machine.  If they shared an identical interface
>> >> then you could hook the lldb-server up to it and it would work either
>> >> locally or remotely.
>> >>
>> >> What was the original motivation for having the api design of remote
>> >> and local process plugins diverge?
>> >
>> > The plan was always do remote so we are always using one thing. We
>> > started off thinking we wanted to have a native plug-in and a remote GDB
>> > server, but when we found we didn't have serious performance issues we went
>> > the lldb-server/debugserver route for everything on our end. lldb-server
>> > uses NativeProcess and NativeThread as base classes that must be subclassed
>> > and we would make a ProcessNative plug-in that used the native compiled
>> > version of these (like lldb-server does), but then we have two code paths 
>> > to
>> > test: native and remote. So we either have to run twice the number of 
>> > tests,
>> > one local and one remote, so we can make sure native and remote work
>> > correctly, or we just go one route. What would tend to happen is we would
>> > 99.9% of people would do local debugging only and all bugs submitted would
>> > mostly be bugs with the native implementation and remote would suffer and
>> > become neglected. GDB had two different code paths for these so remote
>> > really did suffer and we evolved to use remote only on all our systems.
>> > Another nice reason for this is you can save the GDB remote packet log
>> > traffic when you do encounter a bug and see exactly what happened when a 
>> > bug
>> > happened.
>> >
>> > So due to history, we started thinking we would need both native and
>> > remote plug-ins, but we migrated over time to just one solution for simpler
>> > testing, ensuring remote debugging is rock solid since it is always used 
>> > for
>> > local debugging, and for the convenience of being able to completely lop 
>> > all
>> > traffic to/from the process with the GDB remote logs.
>> >
>> > Greg
>> >
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>> --
>> Stephane Sezer
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>



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

[lldb-dev] GDB Remote target descriptions

Re: [lldb-dev] Conditionally adding sources to the build

[lldb-dev] [Bug 31245] New: Assertion failed: (m_base_dwarf_cu->GetOffset() == die_ref.cu_offset), function GetDIE, file src/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp, line 120

Re: [lldb-dev] Conditionally adding sources to the build

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

5 matches

Site Navigation

Mail list logo

Footer information