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

[Bewoayia Kebianyor via lldb-dev]

Hello,

Thanks to Ted, Pavel and Greg for your reply with suggestion on how to resolve 
the issue. Greg's comment below help me to resolve the issue. 

>I am guessing that maybe your libModel_LLDB_Debugger.so shared
>library can't find all the dependencies it requires when being
>loaded. Try making a small a.out file that links against this library
>and try to run your a.out program. See if you see any errors when the
>a.out tries to launch.

While I already had an executable linking to the library, I didnot call 
functions referencing to Clang and XML parsing from the 
libModel_LLDB_Debugger.so. I simple called a function to print out the size of 
a map container I have within my lib. Which worked fine. Based on Greg's 
comment, I then extended this to call more functions which does the XML parsing 
and AST Parsing, then linking failed with error: undefined reference to 
`typeinfo for clang::ASTConsumer'. I searched on google and found out that this 
error has to do with the fact that LLVM and Clang are compiled with -fno-rtti 
by default and I am not explicitly setting the compile flag -fno-rtti in my 
project. I then added this to the "ASTConsumer derived class" in my project and 
it resolved the issue. 

Thanks once more. 

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

-Greg Clayton  schrieb: -

>An: Bewoayia Kebianyor 
>Von: Greg Clayton 
>Datum: 08.06.2018 18:30
>Kopie: lldb-dev@lists.llvm.org
>Betreff: Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) -
>error: this file does not represent a loadable dylib
>
>Comments inlined below.
>
>
>On Jun 8, 2018, at 2:52 AM, Bewoayia Kebianyor via lldb-dev
> 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. 
>
>Did you know we have the ability to set breakpoints using source
>regular expression?
>
>(lldb) breakpoint set --source-pattern-regexp "// breakpoint [0-9]+"
>--file /path/to/foo.cpp
>
>This will use a regular expression to search the source file for the
>regular expression you specify and have one breakpoint that has
>multiple locations.
>
> 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.
>
>Do you even need this custom command given what I said above?
> 
> 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/libMod
>el_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/libMod
>el_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.
>
>I am

Re: [lldb-dev] Making changes to the SB API

[Leonard Mosescu via lldb-dev]

Thanks. I wasn't sure how well C++ overloading works with SWIG, that's
definitely a more ergonomic solution.


On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton  wrote:

>
>
> On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> What is the governing philosophy around making changes to the SB API? The
> "SB API Coding Rules "
> page establishes the practices on how to avoid introducing accidental
> incompatibility, but what
> about the cases where there's a case for intentionally making changes?
>
> For example, I'd like to make a small change to SBTarget to allow
> surfacing errors during LoadCore():
>
> SBProcess SBTarget::LoadCore(const char *core_file)
>
>
> And add an explicit out error parameter (in line with SBTarget::Attach(),
> Launch(), ...):
>
> SBProcess SBTarget::LoadCore(const char *core_file*, SBError **&**error*)
>
> If the rule is to strictly avoid any kind of changes then I'd have to
> resort to
> a COM-like versioning and introduce a new SBTarget::LoadCore2 (or
> LoadCoreEx, ... pick
> your poison, I'm not set on any name) while also keeping the existing
> LoadCore().
>
> Any guidance on this? Thanks!
>
>
> Just add an extra overloaded version of LoadCore. We don't want people's
> code to not link and since Apple uses a LLDBRPC.framework that sub-launches
> a lldb-rpc-server which can connect to older LLDB.framework binaries, we
> can't remove functions.
>
> Greg
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Making changes to the SB API

[Jim Ingham via lldb-dev]

Overloading with different numbers of arguments works with no problems, and we 
use that in a bunch of places in the SB API.  I seem to remember that SWIG 
doesn't always get more subtle overloading (float vrs. double) right, but I 
can't bring a specific example to mind.  Anyway, Greg's solution should work 
just fine.

Jim

> On Jun 11, 2018, at 12:20 PM, Leonard Mosescu via lldb-dev 
>  wrote:
> 
> Thanks. I wasn't sure how well C++ overloading works with SWIG, that's 
> definitely a more ergonomic solution.
> 
> 
> On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton  wrote:
> 
> 
>> On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev 
>>  wrote:
>> 
>> What is the governing philosophy around making changes to the SB API? The 
>> "SB API Coding Rules"
>> page establishes the practices on how to avoid introducing accidental 
>> incompatibility, but what 
>> about the cases where there's a case for intentionally making changes?
>> 
>> For example, I'd like to make a small change to SBTarget to allow surfacing 
>> errors during LoadCore():
>> 
>> SBProcess SBTarget::LoadCore(const char *core_file)
>> 
>> And add an explicit out error parameter (in line with SBTarget::Attach(), 
>> Launch(), ...):
>> 
>> SBProcess SBTarget::LoadCore(const char *core_file, SBError &error)
>> 
>> If the rule is to strictly avoid any kind of changes then I'd have to resort 
>> to
>> a COM-like versioning and introduce a new SBTarget::LoadCore2 (or 
>> LoadCoreEx, ... pick
>> your poison, I'm not set on any name) while also keeping the existing 
>> LoadCore().
>> 
>> Any guidance on this? Thanks!
>> 
> 
> Just add an extra overloaded version of LoadCore. We don't want people's code 
> to not link and since Apple uses a LLDBRPC.framework that sub-launches a 
> lldb-rpc-server which can connect to older LLDB.framework binaries, we can't 
> remove functions.
> 
> Greg
> 
>> 
>> ___
>> 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