After a long wild goose chase, that didn't get me nowhere I am looking
for some help.
Basically what's not working for me anymore in 9.0.0 is the "expression"
printer `p` (not `po`).
Technically that is a JIT compiled Objective-C category method, where
the resulting binary code gets extracted fr
I don't think that is right for "step-in". As you said above, in the classic
example of a trampoline: objc_msgSend you can't statically know the destination. So the
DWARF can't help resolve this; you would still need to do the work the lldb trampoline
classes do at runtime.
I was thinking
On 24.09.19 19:28, Jim Ingham wrote:
We've had many requests to elide some classes of entries in backtraces - like to mirror the
Xcode display I mentioned previously. Most of these requests don't depend on the functions
being marked artificial. So if we're going to do this, something more g
Nat! schrieb am 24.09.19 um 00:28:
On 23.09.19 19:22, Adrian Prantl wrote:
I think the best mechanism for this would be to ensure that the
trampolines are marked up as DW_AT_artificial and/or DW_AT_trampoline
by the compiler. I'm pretty sure LLDB then already knows how to hide
artificial fra
On 23.09.19 19:22, Adrian Prantl wrote:
I think the best mechanism for this would be to ensure that the trampolines are
marked up as DW_AT_artificial and/or DW_AT_trampoline by the compiler. I'm
pretty sure LLDB then already knows how to hide artificial frames (somebody
else can probably pro
When I am using `bt` to look at my backtrace, I get for a method call
breakpoint in `+[Hello printName:version:]` a stacktrace like this (with
my custom Objective-C runtime):
```
* frame #0: 0x004179b3 test-debugger`+[Hello
printName:version:](self=Hello, _cmd=,
_param=0x7ff
I was asked by the author of lldb-mi, to forward this to the list, since
he is not subscribed:
Illya Rudkin schrieb am 05.07.19 um 10:37:
Hi Nat
Thank you for bring this to my attention. Yes I am the original author
but for a long time now I have not been involved in its further
development
I use a plugin in Visual Studio Code
https://github.com/WebFreak001/code-debug, that uses lldb-mi. It works
fairly well for me.
Ciao
Nat!
On 02.07.19 00:09, Jonas Devlieghere via lldb-dev wrote:
Hi everyone,
After long consideration, I want to propose removing lldb-mi from the
reposit
I second this opinion and have really not much further to add, except
maybe that just yesterday to my delight I actually discovered this
option and now promptly use it as the default when building my debugger
variant. It removed a lot of python warnings when running my handbuilt
lldb on macos.
I couldn't figure out how to post a patch to reviews.llvm.org, so here
it is per email, with the hope that someone adopts it :)
Basically it's just moving the `bool print_oneline` out of the execution
path, if no children are
printed, since this value is then never used. This may not seem lik
Hi
So my real main problem is that I want to run an expression to output
the value of an Objective-C parameter. e.g. `- (void) foo:(id) a`. I
want to print `a` when I am stopped in `foo`.
This isn't working for me - technically, I believe - because, in
`ClangASTContext::AddMethodToObjCObject
Hi
I compiled lldb (relase_40) on linux (ubuntu zesty). It runs, but it has
this strange behaviour that keypresses are echoed as unicode escapes,
but aren't really processed:
Typing "help" here:
```
./bin/lldb
(lldb) \U+4168\U+4165\U+416C\U+4170
error: empty command
(lldb)
```
As anyone see
Pavel, this is pretty much exactly what happens. (Except that there is
no frontend. The substitution is done during CodeGen. But that is just a
detail)
I think a more general solution, that doesn't tie mulle-objc implicitly
to the dwarf format would be better in the long term though.
Ciao
Na
Pavel Labath schrieb:
> I think the cleanest solution would be to actually modify the compiler
> to emit "correct" dwarf (as in, dwarf representing the code as it
> actually looks like to user, and not some internal intermediate
> representation). The dwarf expression in DW_AT_location can easily
>
Let me show you a snippet of a lldb debug session in progress in my ObjC
variant:
```
-10,10,v,18.48
Process 45774 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x00010e2a multiple.debug`+[Foo
long:int:char:float:](self=Foo, _cmd=,
_param
Hi Jim,
Thanks! I didn't know about ThreadPlanShouldStopHere. And your
swift-lldb code does exactly, what I am looking for.
Ciao
Nat!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
I adapted the AppleObjcTrampolineHandler to my runtime. It works in as
much as that the debugger steps over my intermediate C functions and
breaks in the targetted method.
Unfortunately when I step out of the method, I am not back at the ObjC
call (0x00010ebf) but instead in my intermediat
Thanks for the answer, it makes it clearer.
I have my own Objective-C runtime, and I am using AppleV1 as a starting point
for my own LanguageRuntime plugin. I didn't even know, that the vtab wasn't
used anymore in Apple's Objective-C :)
Ciao
Nat!
_
At first I thought it might have something to do with C++. But then I
looked a little closer and then it looked like it is building up
information about information contained in a linked list called
"gdb_objc_trampolines".
A google search yields:
https://opensource.apple.com/source/objc4/ob
From the looks of it, lldb uses
`ObjCLanguageRuntime::LookupInCompleteClassCache` to create a lldb::Type
for an Objective C class, by looking through the modules. In my
circumstances (one being on Linux), it doesn't find a symbol for the
class and puts my classname into `m_negative_complete_cla
Hi
is this funny function AppleObjCRuntimeV1::CreateObjectChecker actually
used ?
First of all the snprintf is wrapped in an assert (!?). If the code gets
compiled with -DNDEBUG, the function would pretty much do nothing.
Second, I guess, that this is some C-code that gets compiled on the
21 matches
Mail list logo
