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
Op 2016-02-17 om 00:32 schreef Jason Molenda:
log enable lldb dyld
Thanks!
so apparently I had a call like:
Error error = lTarget->GetPlatform()->ResolveExecutable(spe, mod, NULL);
if (error.Success()) {
mod->GetObjectFile();
lTarget->SetExecutableModule(mod, false);
}
i
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 plat
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
mailto:lldb-dev@lists.llvm.org>> wrote:
When starting a process on Win32 ther
How do I break on (first chance) exceptions on Windows?
--
Carlo Kok
RemObjects Software
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/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
__
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 th
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
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/l
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/W
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 s
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
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 (
Hi,
I have a piece of debuginfo containing this subfunction :
DW_TAG_subprogram [6] *
DW_AT_low_pc [DW_FORM_addr] (0x00437020)
DW_AT_high_pc [DW_FORM_data4] (0x001e)
DW_AT_frame_base [DW_FORM_exprloc](<0x1> 55 )
DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0
How do I get the dw_at_name field? I don't need lldb to decypher the
mangling I use, I just want access to the linkage name and real encoded
name?
Also how do I get the type this is contained in (presuming there is one
ofc)?
I am not sure what you are trying to do. Can you elaborate a little.
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::SBTypeMember
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 i
On 2017-02-22 18:50, Greg Clayton via lldb-dev wrote:
On Feb 21, 2017, at 5:08 PM, Jim Ingham mailto:jing...@apple.com>> wrote:
On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev
mailto:lldb-
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
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
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*))
21 matches
Mail list logo
