[lldb-dev] Unsupported instruction call

[Carlo Kok via lldb-dev]

Trying to evaluate:

((unsigned short* (*)(void *))10544800)((void*)44769264)

or

((unsigned short* (*)(void *))_ElementsGetTypeName)((void*)44769264)

in lldb/windows gives me
Unsupported instruction: %call = call i16* inttoptr (i32 16967328 to 
i16* (i8*)*)(i8* inttoptr (i32 15867888 to i8*))



Seems to be triggered by support_function_calls being false(but I can't 
see who would ever set this to true)


what am I missing?
--
Carlo Kok
RemObjects Software
___
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
<lldb-dev@lists.llvm.org <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_image_spec,
lldb::SBError);

  //--
  /// 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_image_spec,
 constlldb::SBFileSpec_image_spec,
 lldb::SBError);

  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

[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

Re: [lldb-dev] Too many ModuleSP references

[Carlo Kok via lldb-dev]

On 2017-02-22 18:50, Greg Clayton via lldb-dev wrote:



On Feb 21, 2017, at 5:08 PM, Jim Ingham > wrote:



On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev
> wrote:



On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev
> wrote:


- StepOverBreakpointTestCase: Have the test not store the breakpoints
in the test case object. Basically, declare that this is not a bug,
and it's the users responsibility to clean up necessary objects.


It would be nice to avoid this.





I don't agree with this.  I think trying to force folks using the API
from Python to manually clear all stored objects would be really
obnoxious.  If anything, we should figure out how to make this
accidental failure into an intended failure so we can make sure we
don't end up requiring this kind of micro-management.


It's possible you meant "it would be nice to avoid it's being the
user's responsibility to clean up necessary objects", in which case
sorry for mis-reading but happy we agree...



Yep, that is what I meant. No one should have to worry about cleansing
any variables. It should just work. So we need to pick the lldb::SB
objects that have strong reference very carefully.




I think the same goes for SBValue, whenever I've looked at 'locals' the 
executable gets locked until my SBValue refs get gcd.



--
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] logic reversal in StackFrame::Disassemble in r287189

[Carlo Kok via lldb-dev]

I think something went wrong in r287189:

https://github.com/llvm-mirror/lldb/commit/dfd7c7c89c00bbffcb130cf51cd33058ecb5dfcd#diff-3adb8d2b6f1642f0ae63c3cd9326d6e4L221

First it checked if the disassembly was empty, if not it filled it, now 
it returns null if it's empty (which it will always be initially)


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

Re: [lldb-dev] get function name from dwarf info

[Carlo Kok via lldb-dev]

On 2016-10-12 19:10, Greg Clayton wrote:



We would also need to add a way to get the class type from the member function:

lldb::SBType lldb::SBTypeMemberFunction::GetContainingType();

This would return the class/struct that owns the member function.


So if we just add:

  lldb::SBTypeMemberFunction lldb::SBType::GetMemberFunction();
  lldb::SBType lldb::SBTypeMemberFunction::GetContainingType();

Then you should be able to do what you want. Let me know if you need help with 
this.


Shouldn't that be SBFunction::GetMemberFunction() ?

If you can hint at where this info is stored that would be great. I 
looked at Function but couldn't figure it out.



Besides that, happen to know how I can get the dw_at_name from dwarf 
function to SBFunction? Atm it seems to go through the demangler in 
Function, which fails (there isn't one) and just returns the symbol name 
even though the info is there.

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

Re: [lldb-dev] Psuedo terminal on Windows

[Carlo Kok via lldb-dev]

On 2016-09-12 16:39, Zachary Turner wrote:

Ahh that explains why I didn't notice it. Is the fix straightforward?


Sort of. it works if i (locally) do return 0, but that's doesn't seem to 
be the right thing to do.


The common thing to do on Windows is to let the program create a new 
window (flag in CreateProcess(Ex)), unless any of the 3 are reassigned, 
this would show a new cmd style window where stdin, stdout, stderr 
automatically go to, but that's quite a bit wrapped away from the point 
we call it, at least I coudln't find out how to do that.


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

Re: [lldb-dev] Psuedo terminal on Windows

[Carlo Kok via lldb-dev]

On 2016-09-12 10:06, Carlo Kok via lldb-dev wrote:

Hi,

ProcessLaunchInfo seems to, unconditionally create a pseudo terminal if
there's nothing attached to the stdout/stderr. This seems to end up
calling posix_openpt, which is defined as:

inline int posix_openpt(int flag) { LLVM_BUILTIN_UNREACHABLE; }

for Windows.

This was fine a while ago so I'm wondering, what changed and how do I
work around it?


This seemed to be caused by 278177 (done by zturner), and probably only 
hits when the host application is a gui app instead of a console 
application.



--
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] Psuedo terminal on Windows

[Carlo Kok via lldb-dev]

Hi,

ProcessLaunchInfo seems to, unconditionally create a pseudo terminal if 
there's nothing attached to the stdout/stderr. This seems to end up 
calling posix_openpt, which is defined as:


inline int posix_openpt(int flag) { LLVM_BUILTIN_UNREACHABLE; }

for Windows.

This was fine a while ago so I'm wondering, what changed and how do I 
work around it?

--
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] win64 "patch"

[Carlo Kok via lldb-dev]

Seems win64 almost works fine out of the box. 1 minor thing is needed:


diff --git 
a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp 
b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp

index 103cff4..4b37c3f 100644
--- 
a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
+++ 
b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp

@@ -136,6 +136,8 @@ RegisterInfo g_register_infos[] = {
  nullptr},
 };

+static size_t k_num_register_infos = 
llvm::array_lengthof(g_register_infos);

+
 // Array of lldb register numbers used to define the set of all 
General Purpose Registers
 uint32_t g_gpr_reg_indices[] = {eRegisterIndexRax, eRegisterIndexRbx, 
 eRegisterIndexRcx, eRegisterIndexRdx,
 eRegisterIndexRdi, eRegisterIndexRsi, 
 eRegisterIndexR8,  eRegisterIndexR9,

@@ -169,7 +171,9 @@ RegisterContextWindows_x64::GetRegisterCount()
 const RegisterInfo *
 RegisterContextWindows_x64::GetRegisterInfoAtIndex(size_t reg)
 {
-return _register_infos[reg];
+   if (reg < k_num_register_infos)
+   return _register_infos[reg];
+   return NULL;
 }

 size_t


The unwind logic asks for the "return address register" which doesn't 
exist; returns -1 and goes out of the bounds for g_register_infos.


--
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] Debugging win64 from 32bits

[Carlo Kok via lldb-dev]

Hi,

Is there a good way to debug win64 from a win32 process?

Or is there an "lldb-debugserver" that works on windows that can aid in 
this process?


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

Re: [lldb-dev] break on exceptions/windows

[Carlo Kok via lldb-dev]

Op 2016-04-04 om 20:41 schreef Greg Clayton:



On Apr 4, 2016, at 11:36 AM, Carlo Kok  wrote:






There should be a way then to do a "break on every exception", instead of just 
1 specific code.


That would be easy with the --exception-name:

(lldb) breakpoint set --exception-name=all


and some way for the api to get the payload (which can have a variable number 
of parameters)


What are you thinking here? Example?


I have a frontend language (and I imagine lots of others have one) where 
I can throw exceptions. Windows has no predefined way of how an 
exception object is formatted, you give it a list of pointer sized ints 
and a count, and that's what it fills the exception object with, for 
example I pass:

[0] Return address
[1] frame pointer
[2] Class instance of the exception object
with my custom exception code.

msvc does the same with completely different values. Other languages 
will have their own values. When using the api I would want access to 
the code (To know of it's mine, these are the cods Zachery Turner 
mentioned) and the payload (to get access to the object) so that I show 
what exception occurred and turn it into a string representation.


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

Re: [lldb-dev] break on exceptions/windows

[Carlo Kok via lldb-dev]

Op 2016-04-04 om 20:30 schreef Greg Clayton:



On Apr 4, 2016, at 11:24 AM, Zachary Turner  wrote:

It seems like we already have some precedent for conditional command arguments. 
 For example:

(lldb) help platform process list
...
-u  ( --uid  )
 [POSIX] Find processes that have a matching user ID.

So on Windows this argument doesn't make sense.  Could we make an argument that 
is conditional on the *target* rather than the host?  Then, for example, you 
could have something like this:

(lldb) help break set
...
--code  ( --code  )
 [Windows Target] Break when the exception with code  is 
raised.

How to plumb this to the ProcessWindows plugin is an open question, but should 
be mostly mechanical.


This is like my suggestion of:

(lldb) breakpoint set --exception-code 0x40010005

The code can be passed to the current Platform along with the current target:

Error Platform::SetExceptionBreakpointWithExceptionCode (lldb_private::Target 
*target, uint64_t exception_code);

The process can be extracted from the target when the breakpoint needs to be 
resolved.




There should be a way then to do a "break on every exception", instead 
of just 1 specific code.


and some way for the api to get the payload (which can have a variable 
number of parameters)


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

Re: [lldb-dev] break on exceptions/windows

[Carlo Kok via lldb-dev]

Op 2016-04-04 om 16:00 schreef Zachary Turner:

Not possible currently, although it wouldn't be too hard to add. Would
be a welcome feature if you are interested



I'm (obviously?) interested. But wouldn't know where to start.

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

Re: [lldb-dev] exception "leaks" to debugger for win32

[Carlo Kok via lldb-dev]

ah yes! Disabling that fixed it. Thanks

Op 2016-03-18 om 19:29 schreef Zachary Turner:

Are you launching the process with -s (stop at entry)?

On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev
<lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote:

When starting a process on Win32 there's an internal exception
(breakpint) that leaks to the debug caller:
s   'Exception 0x8003 encountered at address 0x7789ccbc'#0

This one is dealt with by the debugger internally but there's still a
StateType.eStateStopped event for it. On other platforms there's no
exception like this for the internal start breakpoint (note that actual
breakpoints after this hit just fine)

--
Carlo Kok
RemObjects Software
___
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



--
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] exception "leaks" to debugger for win32

[Carlo Kok via lldb-dev]

When starting a process on Win32 there's an internal exception 
(breakpint) that leaks to the debug caller:

s   'Exception 0x8003 encountered at address 0x7789ccbc'#0

This one is dealt with by the debugger internally but there's still a 
StateType.eStateStopped event for it. On other platforms there's no 
exception like this for the internal start breakpoint (note that actual 
breakpoints after this hit just fine)


--
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] No breakpoints after update

[Carlo Kok via lldb-dev]

After updating lldb to latest (from ~october) i'm not getting any hits 
anymore for any breakpoints.


I'm remote debugging from Windows to OSX, the Platform (MacOS), ABI 
(sysV) all seems fine. the language runtime doesn't load yet but from 
what I've seen during debugging it never actually gets a dyld breakpoint 
hit.


Log is here:

http://pastebin.com/raw/NyUUed0v

checked every line, didn't see anything obvious. Any hints at what I can 
try would be appreciated.


Thanks.

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