[lldb-dev] [LLDB on windows] Win32 API UnDecorateSymbolName not thread safe

[olizit via lldb-dev]

Hello,

As written in MSDN documentation
https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms681400%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
UnDecorateSymbolName function is not thread safe and must be mutex guarded.

Thanks,

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

[lldb-dev] [LLDB on windows] Step out is not working

[olizit via lldb-dev]

Hello,

Compile this sample program with clang 3.9.1 in 64bits mode
#include 

int my_func(char c, double d)
{
std::cout << "c: " << c << std::endl;
std::cout << "d:" << d << std::endl;
return 0;
}

int main(int argc, char const *argv[])
{
int i = 0;
i++;
i++;
my_func('a', 10.1);
i++;
i++;
return 0;
}

compile commande line :
clang++ -x c++ -target "x86_64-pc-windows-msvc" -O0 -glldb -gdwarf-4 -D
_WIN32 -D _WIN64 -D _CONSOLE -D NDEBUG -D _DEBUG -D _MT -D _DLL -c -o
main.o main.cpp
lld-link /out:main.exe /machine:X64 /nxcompat /incremental  /nologo /wx
/subsystem:console /debug vcruntimed.lib msvcrtd.lib main.o

run lldb and enter commands
target create "main.exe"
b main.cpp:14
r

First step over (n command) is ok but second step over goes into my_func
function.


Thanks,

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

Re: [lldb-dev] DWARF v5 unit headers

[Tamas Berghammer via lldb-dev]

As far as I know the only dwarf v5 functionality currently implemented in
LLDB is the split dwarf support so I don't expect it to work with the new
dwarf v5 data but as long as clang emits dwarf v4 (or older) by default it
shouldn't cause any immediate problem with the test suite (we will still
have to teach LLDB to handle dwarf v5).

For the future changes, when you start to emit the new dwarf v5 tag and
form values instead of the current GNU extension tag and form values for
split dwarf and for the related new data form-s we will have to teach LLDB
to understand them (currently we expect only the GNU versions) so a heads
up for that change would be appreciated. Other then this I expect no issue
regarding the addition of dwarf v5 support for LLDB.

Tamas

On Tue, Feb 28, 2017 at 5:25 AM Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will
> cause Clang/LLVM to emit correct unit headers if you ask for version 5.
> I've run the lldb tests and I *think* I pointed to my modified Clang
> correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
> not introduce new problems.
> I saw 3 Failure and 12 Error with or without the patch.
> (One Expected Failure seems to have become an Unexpected Success. Haven't
> tried to decipher logs to figure out which one yet.)
>
> If anybody can predict a problem with my patch, please let me know by
> noon Pacific time (2000 GMT) tomorrow (28th).
>
> We're going to be doing more work implementing various bits of DWARF v5
> in the coming months.  If anybody thinks they can predict that there are
> particular bits that would be especially problematic for LLDB, it would
> be useful to know up front which bits those are.
>
> Thanks
> --paulr
>
> ___
> 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] DWARF v5 unit headers

[Pavel Labath via lldb-dev]

Thanks for the heads up Paul. I've tried your change on linux, and I don't
see any regressions, so it should be safe to land.

Regarding the test failures you were seeing: what is the system you were
testing this on? If it is linux, could you send me the list of failures --
I'd be interested in getting them sorted out.

regards,
pavel



On 28 February 2017 at 11:45, Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> As far as I know the only dwarf v5 functionality currently implemented in
> LLDB is the split dwarf support so I don't expect it to work with the new
> dwarf v5 data but as long as clang emits dwarf v4 (or older) by default it
> shouldn't cause any immediate problem with the test suite (we will still
> have to teach LLDB to handle dwarf v5).
>
> For the future changes, when you start to emit the new dwarf v5 tag and
> form values instead of the current GNU extension tag and form values for
> split dwarf and for the related new data form-s we will have to teach LLDB
> to understand them (currently we expect only the GNU versions) so a heads
> up for that change would be appreciated. Other then this I expect no issue
> regarding the addition of dwarf v5 support for LLDB.
>
> Tamas
>
> On Tue, Feb 28, 2017 at 5:25 AM Robinson, Paul via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I'm planning to commit a patch (http://reviews.llvm.org/D30206) which
>> will
>> cause Clang/LLVM to emit correct unit headers if you ask for version 5.
>> I've run the lldb tests and I *think* I pointed to my modified Clang
>> correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
>> not introduce new problems.
>> I saw 3 Failure and 12 Error with or without the patch.
>> (One Expected Failure seems to have become an Unexpected Success. Haven't
>> tried to decipher logs to figure out which one yet.)
>>
>> If anybody can predict a problem with my patch, please let me know by
>> noon Pacific time (2000 GMT) tomorrow (28th).
>>
>> We're going to be doing more work implementing various bits of DWARF v5
>> in the coming months.  If anybody thinks they can predict that there are
>> particular bits that would be especially problematic for LLDB, it would
>> be useful to know up front which bits those are.
>>
>> Thanks
>> --paulr
>>
>> ___
>> 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] Load object file on the fly

[Carlo Kok via lldb-dev]

As far as I can tell from reading the source LLDB has facilities to load 
a "jitted" clang fragment as an object file, load it into the target 
process "run" it and unload it. Could this process be reused externally? 
Say from the SB or lower level apis?


What I want to accomplish is allow better expression evaluation for my 
own languages by compling a piece of code to an object file (coff/elf, 
whatever), passing all locals/args as arguments to this and getting the 
evaluated result out of it. Is something like this possible?


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

[lldb-dev] [Bug 32090] New: DynamicLoaderPOSIXDyld crashes if an app dies before hitting the entry breakpoint

[via lldb-dev]

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

Bug ID: 32090
   Summary: DynamicLoaderPOSIXDyld crashes if an app dies before
hitting the entry breakpoint
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org

This happens because it uses a one-shot breakpoint to do it's processing.
However, if the process dies before the breakpoint is hit, then it will be
triggered the next time the process is started. However, it will be still
referring to the old process (which is now gone). Hilarity ensues..

-- 
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] [LLDB on windows] Win32 API UnDecorateSymbolName not thread safe

[Zachary Turner via lldb-dev]

Thanks for catching this, should be an easy fix. I'll try to get something
in this week
On Tue, Feb 28, 2017 at 3:34 AM olizit via lldb-dev 
wrote:

> Hello,
>
> As written in MSDN documentation
> https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms681400%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
> UnDecorateSymbolName function is not thread safe and must be mutex guarded.
>
> Thanks,
>
> Olivier
>
> ___
> 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] DWARF v5 unit headers

[Robinson, Paul via lldb-dev]

Thanks for the feedback!  Clang will continue to emit v4 by default for quite 
some time, the v5 work is just getting started.
Would someone like to be subscribed to LLVM reviews that do new v5 work?  Or 
just rely on us remembering to send notes to lldb-dev?
Once I get the unit headers in place, my focus is likely to be on the features 
that reduce the number of relocations that the linker has to process.  This 
would include the new indirect forms for strings and addresses.

Pavel, I will start a new thread about the failures I see on Linux.
Thanks,
--paulr

From: Pavel Labath [mailto:lab...@google.com]
Sent: Tuesday, February 28, 2017 3:55 AM
To: Robinson, Paul
Cc: LLDB Dev (lldb-dev@lists.llvm.org); Tamas Berghammer
Subject: Re: [lldb-dev] DWARF v5 unit headers

Thanks for the heads up Paul. I've tried your change on linux, and I don't see 
any regressions, so it should be safe to land.

Regarding the test failures you were seeing: what is the system you were 
testing this on? If it is linux, could you send me the list of failures -- I'd 
be interested in getting them sorted out.

regards,
pavel



On 28 February 2017 at 11:45, Tamas Berghammer via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
As far as I know the only dwarf v5 functionality currently implemented in LLDB 
is the split dwarf support so I don't expect it to work with the new dwarf v5 
data but as long as clang emits dwarf v4 (or older) by default it shouldn't 
cause any immediate problem with the test suite (we will still have to teach 
LLDB to handle dwarf v5).

For the future changes, when you start to emit the new dwarf v5 tag and form 
values instead of the current GNU extension tag and form values for split dwarf 
and for the related new data form-s we will have to teach LLDB to understand 
them (currently we expect only the GNU versions) so a heads up for that change 
would be appreciated. Other then this I expect no issue regarding the addition 
of dwarf v5 support for LLDB.

Tamas

On Tue, Feb 28, 2017 at 5:25 AM Robinson, Paul via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will
cause Clang/LLVM to emit correct unit headers if you ask for version 5.
I've run the lldb tests and I *think* I pointed to my modified Clang
correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
not introduce new problems.
I saw 3 Failure and 12 Error with or without the patch.
(One Expected Failure seems to have become an Unexpected Success. Haven't
tried to decipher logs to figure out which one yet.)

If anybody can predict a problem with my patch, please let me know by
noon Pacific time (2000 GMT) tomorrow (28th).

We're going to be doing more work implementing various bits of DWARF v5
in the coming months.  If anybody thinks they can predict that there are
particular bits that would be especially problematic for LLDB, it would
be useful to know up front which bits those are.

Thanks
--paulr

___
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] Load object file on the fly

[Greg Clayton via lldb-dev]

> On Feb 28, 2017, at 4:19 AM, Carlo Kok via lldb-dev  
> wrote:
> 
> As far as I can tell from reading the source LLDB has facilities to load a 
> "jitted" clang fragment as an object file, load it into the target process 
> "run" it and unload it. Could this process be reused externally? Say from the 
> SB or lower level apis?
> 
> What I want to accomplish is allow better expression evaluation for my own 
> languages by compling a piece of code to an object file (coff/elf, whatever), 
> passing all locals/args as arguments to this and getting the evaluated result 
> out of it. Is something like this possible?

Yes. In SBProcess you can load a shared library and unload it:

  //--
  /// Load a shared library into this process.
  ///
  /// @param[in] remote_image_spec
  /// The path for the shared library on the target what you want
  /// to load.
  ///
  /// @param[out] error
  /// An error object that gets filled in with any errors that
  /// might occur when trying to load the shared library.
  ///
  /// @return
  /// A token that represents the shared library that can be
  /// later used to unload the shared library. A value of
  /// LLDB_INVALID_IMAGE_TOKEN will be returned if the shared
  /// library can't be opened.
  //--
  uint32_t LoadImage(lldb::SBFileSpec &remote_image_spec, lldb::SBError &error);

  //--
  /// Load a shared library into this process.
  ///
  /// @param[in] local_image_spec
  /// The file spec that points to the shared library that you
  /// want to load if the library is located on the host. The
  /// library will be copied over to the location specified by
  /// remote_image_spec or into the current working directory with
  /// the same filename if the remote_image_spec isn't specified.
  ///
  /// @param[in] remote_image_spec
  /// If local_image_spec is specified then the location where the
  /// library should be copied over from the host. If
  /// local_image_spec isn't specified, then the path for the
  /// shared library on the target what you want to load.
  ///
  /// @param[out] error
  /// An error object that gets filled in with any errors that
  /// might occur when trying to load the shared library.
  ///
  /// @return
  /// A token that represents the shared library that can be
  /// later used to unload the shared library. A value of
  /// LLDB_INVALID_IMAGE_TOKEN will be returned if the shared
  /// library can't be opened.
  //--
  uint32_t LoadImage(const lldb::SBFileSpec &local_image_spec,
 const lldb::SBFileSpec &remote_image_spec,
 lldb::SBError &error);

  lldb::SBError UnloadImage(uint32_t image_token);


> -- 
> Carlo Kok
> RemObjects Software
> ___
> 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] Recent Linux test failures

[Robinson, Paul via lldb-dev]

Also, if I do 'ninja check-all' then I get a compile-time error in
lldb/unittests/Core/LogTest.cpp (line 24):
could not convert '(const char*)"log foo"' from 'const char*' to 
'llvm::StringLiteral'

Thanks,
--paulr


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Robinson, Paul via lldb-dev
> Sent: Tuesday, February 28, 2017 9:10 AM
> To: LLDB Dev (lldb-dev@lists.llvm.org)
> Subject: [lldb-dev] Recent Linux test failures
> 
> Yesterday I mentioned that I had some LLDB test failures while trying an
> LLVM patch, and Pavel requested more details.
> 
> This morning I built clang/llvm/lldb r296443; I had done
>   cmake -DLLDB_TEST_COMPILER=$PWD/bin/clang
> so that 'ninja check-lldb' would make use of the just-built clang.
> 
> 'ninja check-lldb' reported 3 Failures and 12 Errors.  I found some
> log files in 'lldb-test-traces' so I zipped up Failure* and attached
> it to this email.  Let me know if you need other information.
> 
> Thanks,
> --paulr

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

Re: [lldb-dev] DWARF v5 unit headers

[Greg Clayton via lldb-dev]

I look forward to seeing DWARF5 support integrated into LLDB. No problems that 
I know of that you will run into. Please include me in on the LLDB related 
patches for DWARF5. One particular area of interest is the emission of the new 
accelerator tables and having LLDB support them. I believe the new DWARF5 
standard specifies name accelerator tables that replace the ones we make on 
Apple platforms and have been using for many years. They speed debugging up on 
linux by a lot so as the current code doesn't trust any DWARF accelerator 
tables and it indexes the DWARF manually.

> On Feb 27, 2017, at 9:25 PM, Robinson, Paul via lldb-dev 
>  wrote:
> 
> I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will
> cause Clang/LLVM to emit correct unit headers if you ask for version 5.
> I've run the lldb tests and I *think* I pointed to my modified Clang
> correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
> not introduce new problems.
> I saw 3 Failure and 12 Error with or without the patch.
> (One Expected Failure seems to have become an Unexpected Success. Haven't
> tried to decipher logs to figure out which one yet.)
> 
> If anybody can predict a problem with my patch, please let me know by
> noon Pacific time (2000 GMT) tomorrow (28th).
> 
> We're going to be doing more work implementing various bits of DWARF v5
> in the coming months.  If anybody thinks they can predict that there are 
> particular bits that would be especially problematic for LLDB, it would 
> be useful to know up front which bits those are.
> 
> Thanks
> --paulr
> 
> ___
> 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 on windows] Step out is not working

[Jim Ingham via lldb-dev]

I presume you meant "step over is not working" in the Subject?

The call to std::cout... ends up inserting quite a number of inlined function 
calls into my_func.  clang is not always great at generating coherent 
line-table and inlined subroutine ranges for deeply nested inlining, so that 
the stepping machinery can't safely figure out how to get out of the inlining, 
and ends up stopping.  This example actually works correctly on macOS with a 
recent clang, but this has been an ongoing issue for a while now.

lldb currently always implements "step over" as "step in" followed by "step 
out".  This saves us the (sometimes surprisingly tricky) work of predicting 
where a particular call will go, and where it will return to.  But it does 
leave us vulnerable to errors in the debug information at the callee site.  It 
would be nice to add a set of "vanilla" calls that we're sure we can predict, 
and for those we could just break on the return address and not even bother to 
step in.  That would likely remove this sort of stumble in a lot of cases.

OTOH, you should still file a bug about this.  As I said, this works correctly 
on current TOT lldb/clang 802 on macOS.  So it may also be some issue with the 
Windows port unrelated to this debug info problem.

Jim

> On Feb 28, 2017, at 3:35 AM, olizit via lldb-dev  
> wrote:
> 
> Hello,
> 
> Compile this sample program with clang 3.9.1 in 64bits mode
> #include 
> 
> int my_func(char c, double d)
> {
>   std::cout << "c: " << c << std::endl;
>   std::cout << "d:" << d << std::endl;
>   return 0;
> }
> 
> int main(int argc, char const *argv[])
> {
>   int i = 0;
>   i++;
>   i++;
>   my_func('a', 10.1);
>   i++;
>   i++;
>   
>   return 0;
> }
> 
> compile commande line :
> clang++ -x c++ -target "x86_64-pc-windows-msvc" -O0 -glldb -gdwarf-4 -D 
> _WIN32 -D _WIN64 -D _CONSOLE -D NDEBUG -D _DEBUG -D _MT -D _DLL -c -o main.o 
> main.cpp 
> lld-link /out:main.exe /machine:X64 /nxcompat /incremental  /nologo /wx 
> /subsystem:console /debug vcruntimed.lib msvcrtd.lib main.o
> 
> run lldb and enter commands
> target create "main.exe"
> b main.cpp:14
> r
> 
> First step over (n command) is ok but second step over goes into my_func 
> function.
> 
> 
> Thanks,
> 
> Olivier
> ___
> 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] Recent Linux test failures

[Pavel Labath via lldb-dev]

Thank you Paul. Could you paste the output of the "check-lldb" command?

The LogTest.cpp thing looks like a gcc issue I ran into earlier, I'll have
that fixed shortly.

cheers,
pl


On 28 February 2017 at 17:39, Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Also, if I do 'ninja check-all' then I get a compile-time error in
> lldb/unittests/Core/LogTest.cpp (line 24):
> could not convert '(const char*)"log foo"' from 'const char*' to
> 'llvm::StringLiteral'
>
> Thanks,
> --paulr
>
>
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> > Robinson, Paul via lldb-dev
> > Sent: Tuesday, February 28, 2017 9:10 AM
> > To: LLDB Dev (lldb-dev@lists.llvm.org)
> > Subject: [lldb-dev] Recent Linux test failures
> >
> > Yesterday I mentioned that I had some LLDB test failures while trying an
> > LLVM patch, and Pavel requested more details.
> >
> > This morning I built clang/llvm/lldb r296443; I had done
> >   cmake -DLLDB_TEST_COMPILER=$PWD/bin/clang
> > so that 'ninja check-lldb' would make use of the just-built clang.
> >
> > 'ninja check-lldb' reported 3 Failures and 12 Errors.  I found some
> > log files in 'lldb-test-traces' so I zipped up Failure* and attached
> > it to this email.  Let me know if you need other information.
> >
> > Thanks,
> > --paulr
>
> ___
> 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] Load object file on the fly

[Carlo Kok via lldb-dev]

On 2017-02-28 18:36, Greg Clayton wrote:



On Feb 28, 2017, at 4:19 AM, Carlo Kok via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

As far as I can tell from reading the source LLDB has facilities to
load a "jitted" clang fragment as an object file, load it into the
target process "run" it and unload it. Could this process be reused
externally? Say from the SB or lower level apis?

What I want to accomplish is allow better expression evaluation for my
own languages by compling a piece of code to an object file (coff/elf,
whatever), passing all locals/args as arguments to this and getting
the evaluated result out of it. Is something like this possible?


Yes. In SBProcess you can load a shared library and unload it:

  //--
  /// Load a shared library into this process.
  ///
  /// @param[in] remote_image_spec
  /// The path for the shared library on the target what you want
  /// to load.
  ///
  /// @param[out] error
  /// An error object that gets filled in with any errors that
  /// might occur when trying to load the shared library.
  ///
  /// @return
  /// A token that represents the shared library that can be
  /// later used to unload the shared library. A value of
  /// LLDB_INVALID_IMAGE_TOKEN will be returned if the shared
  /// library can't be opened.
  //--
  uint32_tLoadImage(lldb::SBFileSpec&remote_image_spec,
lldb::SBError&error);

  //--
  /// Load a shared library into this process.
  ///
  /// @param[in] local_image_spec
  /// The file spec that points to the shared library that you
  /// want to load if the library is located on the host. The
  /// library will be copied over to the location specified by
  /// remote_image_spec or into the current working directory with
  /// the same filename if the remote_image_spec isn't specified.
  ///
  /// @param[in] remote_image_spec
  /// If local_image_spec is specified then the location where the
  /// library should be copied over from the host. If
  /// local_image_spec isn't specified, then the path for the
  /// shared library on the target what you want to load.
  ///
  /// @param[out] error
  /// An error object that gets filled in with any errors that
  /// might occur when trying to load the shared library.
  ///
  /// @return
  /// A token that represents the shared library that can be
  /// later used to unload the shared library. A value of
  /// LLDB_INVALID_IMAGE_TOKEN will be returned if the shared
  /// library can't be opened.
  //--
  uint32_tLoadImage(constlldb::SBFileSpec&local_image_spec,
 constlldb::SBFileSpec&remote_image_spec,
 lldb::SBError&error);

  lldb::SBErrorUnloadImage(uint32_timage_token);



Does that work with (non shared, not linked) object files too? Because 
SO's have different visibility rules (And on windows they work 
completely different with exports/imports) which will probably interfere 
with using it as underlying logic for evaluating?


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