[lldb-dev] Unsupported instruction call
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
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
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
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
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
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
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
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
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"
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
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
Op 2016-04-04 om 20:41 schreef Greg Clayton: On Apr 4, 2016, at 11:36 AM, Carlo Kokwrote: 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
Op 2016-04-04 om 20:30 schreef Greg Clayton: On Apr 4, 2016, at 11:24 AM, Zachary Turnerwrote: 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
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
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
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
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