[lldb-dev] Stumped on the missing FindExternalLexicalDecls call

[Nat! via lldb-dev]

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 from and executed in the 
executable.


When I enabled `log enable lldb expr` on 8.0.0 I see the following on `p 
*self`:


```
mulle-lldb   Frame has language of type objective-c
mulle-lldb   Using x86_64--linux as the target triple
mulle-lldb   Using SIMD alignment: 128
mulle-lldb   Target datalayout string: 
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

mulle-lldb   Target ABI: ''
mulle-lldb   Target vector alignment: 0
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[7] for 
'$__lldb_objc_class' in a 'TranslationUnit'

mulle-lldb CEDM::FEVD[7] Searching the root namespace
mulle-lldb FEVD[7] Adding type for $__lldb_objc_class: Foo
mulle-lldb   [ClangASTImporter] Imported 
(ObjCInterfaceDecl*)0x14e76c0, named Foo (from (Decl*)0x7fda7801b558), 
metadata 0x002a
mulle-lldb   [ClangASTImporter] Decl has no origin information 
in (ASTContext*)0x7fda78009bf0
mulle-lldb   [ClangASTImporter] To is an ObjCInterfaceDecl - 
attributes  Lexical Visible HasDefinition
mulle-lldb   ClangASTSource::FindExternalVisibleDecls[7] on 
(ASTContext*)0x13e5610 for '$__lldb_objc_class' in a 'TranslationUnit'

mulle-lldb CAS::FEVD[7] Searching the root namespace
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[8] for 
'$__lldb_arg' in a 'TranslationUnit'

mulle-lldb CEDM::FEVD[8] Searching the root namespace
mulle-lldb   ClangASTSource::FindExternalVisibleDecls[8] on 
(ASTContext*)0x13e5610 for '$__lldb_arg' in a 'TranslationUnit'

mulle-lldb CAS::FEVD[8] Searching the root namespace
mulle-lldb   FindExternalLexicalDecls[6] on (ASTContext*)0x13e5610 
in 'Foo' (ObjCInterfaceDecl*)0x14e76c0
mulle-lldb FELD[6] Original decl (ASTContext*)0x7fda78009bf0 
(Decl*)0x7fda7801b558:

mulle-lldb   @interface Foo
mulle-lldb   @end
mulle-lldb FELD[6] Adding [to ObjCInterfaceDecl Foo] lexical 
ObjCMethodDecl + (void)main
mulle-lldb   [ClangASTImporter] Imported 
(ObjCMethodDecl*)0x14e7dd8, named main (from (Decl*)0x7fda7801b670), 
metadata 0x0033
mulle-lldb   [ClangASTImporter] Decl has no origin information 
in (ASTContext*)0x7fda78009bf0

mulle-lldb   Last statement is an lvalue with type: Class
mulle-lldb   Found function +[Foo($__lldb_category) $__lldb_expr:] 
for $__lldb_expr
mulle-lldb   PrepareForExecution - Current expression language is 
objective-c

```

Here is some stipulation: `[ClangASTImporter] Imported 
(ObjCInterfaceDecl*)0x14e76c0, named Foo (from (Decl*)0x7fda7801b558), 
metadata 0x002a` is the ObjcInterfaceDecl as derived from 
DWARF but not yet filled in with the complete instance variable 
information. The FindExternalLexicalDecls then completes the declaration 
from DWARF info.


This is what happens in 9.0.0:

```
mulle-lldb   Frame has language of type objective-c
mulle-lldb   Using x86_64-unknown-linux-gnu as the target triple
mulle-lldb   Using SIMD alignment: 128
mulle-lldb   Target datalayout string: 
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

mulle-lldb   Target ABI: ''
mulle-lldb   Target vector alignment: 0
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[5] for 
'$__lldb_objc_class' in a 'TranslationUnit'

mulle-lldb CEDM::FEVD[5] Searching the root namespace
mulle-lldb FEVD[5] Adding type for $__lldb_objc_class: Foo
mulle-lldb   [ClangASTImporter] Imported 
(ObjCInterfaceDecl*)0xfe58b0, named Foo (from (Decl*)0x7f6f40047038), 
metadata 0x7fff1672
mulle-lldb   [ClangASTImporter] Decl has no origin information 
in (ASTContext*)0x7f6f40005590
mulle-lldb   [ClangASTImporter] To is an ObjCInterfaceDecl - 
attributes  Lexical Visible
mulle-lldb   ClangASTSource::FindExternalVisibleDecls[4] on 
(ASTContext*)0x1051e20 for '$__lldb_objc_class' in a 'TranslationUnit'

mulle-lldb CAS::FEVD[4] Searching the root namespace
mulle-lldb   [CompleteObjCInterfaceDecl] on 
(ASTContext*)0x1051e20 Completing an ObjCInterfaceDecl named Foo

mulle-lldb [COID] Before:
mulle-lldb [COID] @class Foo;
mulle-lldb [COID] After:
mulle-lldb [COID] @class Foo;
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[6] for 
'$__lldb_arg' in a 'TranslationUnit'

mulle-lldb CEDM::FEVD[6] Searching the root namespace
mulle-lldb   ClangASTSource::FindExternalVisibleDecls[5] on 
(ASTContext*)0x1051e20 for '$__lldb_arg' in a 'TranslationUnit'

mulle-lldb CAS::FEVD[5] Searching the root namespace
mulle-lldb   [CompleteObjCInterfaceDecl] on 
(ASTContext*)0x1051e20 Completing

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

[Nat! via lldb-dev]

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 along the line of the debugger looking examining the 
stack frame after a step and if it is marked as artificial continuing to 
do "stepi" until it hits a frame that isn't marked artificial. That 
would work for quite a bit of code (probably most of mine :). But I can 
see that the scheme would fail, if the trampoline code needs to execute 
a stdlib function or some such (maybe on a cache miss).


Ciao
   Nat!


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

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

[Nat! via lldb-dev]

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 general than just 
"marked artificial" -> elided anyway.

Jim




Yes.

Having done a little further research... Artificial won't work for 
general cases anyway, since it's restricted to inline code (for some 
reason) on gcc and clang. I wonder why, since for a function the only 
real effect is to emit DW_AT_artificial (AFAIK). The restriction seems 
arbitrary and DWARF wouldn't mind.. But the compilers do, so it seems 
out anyway.


DW_AT_trampoline isn't supported by llvm. As I read the description of 
DW_AT_trampoline, its more like a hardcoded vector (a->b), so not useful 
for cases like objc_msgSend, where you don't know the destination a priori.


If I look at the DWARF spec, I don't see any other way to mark a 
function as "boring". I still think this would be a good thing, as this 
would be useful for other debuggers as well, which could instantly work. 
Also a lot of code in the lldb Trampoline classes, for step-in and 
step-out could probably just be removed.


Ciao
   Nat!

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

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

[Nat! via lldb-dev]

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 frames (somebody else can probably provide pointers for how 
that works).


-- adrian

That's a good idea. I can just put __attribute__((artificial)__ on my 
dispatch functions. That's the low-hanging-fruit code I like :)

And though it might not fully work yet with lldb , it may in the future.



Unfortunately clang complains that the "'artificial' attribute only 
applies to inline functions" (why ?). Bummer.


Ciao
   Nat!

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

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

[Nat! via lldb-dev]

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 provide pointers for how that works).

-- adrian

That's a good idea. I can just put __attribute__((artificial)__ on my 
dispatch functions. That's the low-hanging-fruit code I like :)

And though it might not fully work yet with lldb , it may in the future.


On 23.09.19 20:36, Jim Ingham wrote:

lldb can step through trampolines (and step back out again in some cases).  But 
there isn't any support for suppressing the printing of frames.

One way to add this is to use the "Frame Recognizers" Kuba added to lldb recently.  The 
use he had for them was to produce artificial variables for frames you don't have debug information 
for.  But one of the other jobs I had envisioned for frame recognizers was to mark frames as 
uninteresting for printing.  Then you could hook up "bt" to suppress frames that the 
recognizer marked this way.  Since you can add recognizers in Python, this is a fairly attractive 
way to go, since people could adjust their printing to suppress frames not interesting to them.  
And of course, as Adrian suggested, recognizers could consult the debug info as well to suppress 
DW_AT_artificial and DW_AT_trampoline.

Ha. Having to deal additionally with python is not what I call 
attractive :)


Thanks for those reponses. Very helpful.

Ciao
   Nat!

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

[lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

[Nat! via lldb-dev]

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=0x7fffd8a8, name=, version=) at 
main.m:21:21
    frame #1: 0x004bb659 
test-debugger`_mulle_objc_object_call_class_nofail(obj=0x0066a200, 
methodid=3009363030, parameter=0x7fffd8a8, 
cls=0x0066a3e0) at mulle-objc-call.c:668:13
    frame #2: 0x004bbe60 
test-debugger`_mulle_objc_object_call_class(obj=0x0066a200, 
methodid=3009363030, parameter=0x7fffd8a8, 
cls=0x0066a3e0) at mulle-objc-call.c:939:18
    frame #3: 0x004bcb63 
test-debugger`_mulle_objc_object_call_class_needcache(obj=0x0066a200, 
methodid=3009363030, parameter=0x7fffd8a8, 
cls=0x0066a3e0) at mulle-objc-call.c:1320:13
    frame #4: 0x004bcf61 
test-debugger`mulle_objc_object_call(obj=0x0066a200, 
methodid=3009363030, parameter=0x7fffd8a8) at 
mulle-objc-call.c:1379:13
    frame #5: 0x00417a28 test-debugger`main(argc=1, 
argv=0x7fffd9c8) at main.m:29:4

```

I have my Plugin/LanguageRuntime/ObjC/MulleObjC added to lldb and it is 
working fine for stepping through from "main" to "-[Hello 
printName:version:]" directly. Now I wonder, if there are provisions in 
lldb to extend this idea of trampoline hiding to stacktraces (preferably 
as an option), so the stacktrace would look like this:



```
  * frame #0: 0x004179b3 test-debugger`+[Hello 
printName:version:](self=Hello, _cmd=, 
_param=0x7fffd8a8, name=, version=) at 
main.m:21:21
   frame #5: 0x00417a28 test-debugger`main(argc=1, 
argv=0x7fffd9c8) at main.m:29:4

```

Ciao
    Nat!

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

Re: [lldb-dev] [RFC] Removing lldb-mi

[Nat! via lldb-dev]

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 or maintenance. I have been popping in to the Git repository 
occasionally to see the activity and it seems to me there are people 
actively maintaining to this day, either fixing commands or adding new 
ones. This is not very often mind perhaps indicating its maturity. Of 
course this does not indicate the number of people actively using it 
today or how they access the tool to use it, Eclipse users being main 
ones in the past. I am not sure how to get this information.


(To the others in this discussion) Anyway to the point of the this 
discussion I do not mind if it stays where it is currently or is moved. 
The thing I would say is just remember even if you may not be using it 
or interested in it there may be others who are. It may be a bit of 
noise for you but it is a dependency for them. Perhaps reach out before 
making a decision.


All the best

Illya

*From: *Nat! 
*Date: *Thursday, 4 July 2019 at 22:21
*To: *Illya Rudkin 
*Subject: *Fwd: Re: [lldb-dev] [RFC] Removing lldb-mi

Hi

I am forwarding you this, because I believe you are the original author 
of lldb-mi. I think I prefer, if it would stay in the project, but I am 
not really sure.


Ciao
    Nat!


 Forwarded Message 

*Subject: *



Re: [lldb-dev] [RFC] Removing lldb-mi

*Date: *



Thu, 4 Jul 2019 12:24:48 -0700

*From: *



Raphael “Teemperor” Isemann via lldb-dev  



*Reply-To: *



Raphael “Teemperor” Isemann  



*To: *



Davide Italiano  

*CC: *



LLDB  



I just went forward with this and made a quick test repo with an 
out-of-tree lldb-mi that compiles against the system LLDB: 
https://github.com/Teemperor/lldb-mi This seems to work fine with the 
exception of the python tests which require LLDB’s python code for 
testing which isn’t installed alongside LLDB. I guess we will have to 
see if we copy the related test code there or we just rewrite the test 
suite (which is anyway broken). On the upside, we can now just use 
Travis for CI as we don’t have to compile LLVM/Clang/LLDB, so that’s nice.


I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give 
downstream time until 10.0.0 (or X.0.0 :) ) to package out-of-tree 
lldb-mi for users. Given how simple lldb-mi is, this seems like a 
reasonable timeframe.


- Raphael

On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

We're using it with Eclipse and Eclipse based product, so I'd
like to keep as well! :-)...

Zdenek

I do understand that there's desire from people to keep this around
(from an user perspective), but I guess this fundamentally misses
Jonas' original mail point.

lldb-mi has been unmaintained for a long time (at least the past two
years from what I can tell), and we tried to use it in emacs without
success.

It has never been a priority for many of the parties putting effort
in lldb and I'm under the impression the situation won't change in
the foreseeable future.

Unless somebody steps up as maintainer I don't think there's a lot
of future for the tool.

Maybe a good compromise would be that of having lldb-mi living in a
separate repo somewhere on GitHub, as it only uses the SBAPI, which
is public and set in stone?

--

Davide

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



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

Re: [lldb-dev] [RFC] Removing lldb-mi

[Nat! via lldb-dev]

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 
repository. It is basically unmaintained, doesn't match the LLDB code 
style, and worst of all the tests are unreliable if not already 
disabled. As far as I can tell it's missing core functionality to be 
usable from something like say emacs.


Thanks,
Jonas

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


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

Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

[Nat! via lldb-dev]

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.


Ciao
   Nat!


Jim Ingham via lldb-dev 
7. März 2019 um 20:03
Even though you can just use debugserver/lldb-server and debug 
remotely, many people find it handy to be able to run a debugger 
directly on the device they are using. But requiring that you port 
Python and bundle it with your embedded platform just to get a 
debugger there is a pretty big ask. So it is still quite useful to be 
able to build lldb without Python. This option hasn't been broken all 
that frequently in our uses, but if it is being a problem, the better 
solution would be to set up a bot to build with this option, so we can 
make sure it keeps working.


Jim


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


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

[lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded

[Nat! via lldb-dev]

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 like a 
big deal, but solves a big


problem in my debugger :)



```

void ValueObjectPrinter::PrintChildrenIfNeeded(bool value_printed,
   bool summary_printed) {
  // this flag controls whether we tried to display a description for this
  // object and failed if that happens, we want to display the 
children, if any

  bool is_failed_description =
  !PrintObjectDescriptionIfNeeded(value_printed, summary_printed);

  auto curr_ptr_depth = m_ptr_depth;
  bool print_children =
  ShouldPrintChildren(is_failed_description, curr_ptr_depth);

  //
  // DataVisualization::ShouldPrintAsOneLiner is often called for
  // print_oneline (see below) and it is very expensive, so use an
  // early exit, if we are not printing children (also easier to read)
  //
  if (!print_children) {
    if (m_curr_depth >= m_options.m_max_depth && IsAggregate() &&
   ShouldPrintValueObject()) {
  m_stream->PutCString("{...}\n");
    } else
  m_stream->EOL();
    return;
  }

  //
  // TODO: maybe move the bool print_oneline line to #1#, but its 
unclear to
  // me if DataVisualization::ShouldPrintAsOneLiner can modify 
*m_valobj or not

  //
  bool print_oneline =
  (curr_ptr_depth.CanAllowExpansion() || m_options.m_show_types ||
   !m_options.m_allow_oneliner_mode || m_options.m_flat_output ||
   (m_options.m_pointer_as_array) || m_options.m_show_location)
  ? false
  : DataVisualization::ShouldPrintAsOneLiner(*m_valobj);

  bool is_instance_ptr = IsInstancePointer();
  uint64_t instance_ptr_value = LLDB_INVALID_ADDRESS;

  if (is_instance_ptr) {
    instance_ptr_value = m_valobj->GetValueAsUnsigned(0);
    if (m_printed_instance_pointers->count(instance_ptr_value)) {
  // we already printed this instance-is-pointer thing, so don't 
expand it

  m_stream->PutCString(" {...}\n");

  // we're done here - get out fast
  return;
    } else
  m_printed_instance_pointers->emplace(
  instance_ptr_value); // remember this guy for future reference
  }

  // #1#
  if (print_oneline) {
    m_stream->PutChar(' ');
    PrintChildrenOneLiner(false);
    m_stream->EOL();
  } else
    PrintChildren(value_printed, summary_printed, curr_ptr_depth);
}

```


Ciao

   Nat!

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

[lldb-dev] ClangASTContext::AddMethodToObjCObjectType constructs ParmVarDecl without identifier

[Nat! via lldb-dev]

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::AddMethodToObjCObjectType` the name of the parameter 
is omitted in the ParmVarDecl, specifically commented as "anonymous"


```
params.push_back(clang::ParmVarDecl::Create(
  *ast, objc_method_decl, clang::SourceLocation(),
  clang::SourceLocation(),
  nullptr, // anonymous
  method_function_prototype->getParamType(param_index), nullptr,
  clang::SC_Auto, nullptr));
```

I don't really see, how and when this information is added at a later 
stage, but I assune it is somehow. (Not by my ObjC Runtime plugin though)


What I find curious is that the names of the ParmVarDecls have already 
been determined in `DWARFFastParserClang::ParseChildParameters` and are 
saved into `function_param_decls`. That is just ahead of the only call 
to `AddMethodToObjCObjectType` in lldb. But that information isn't 
passed. Is there a reason why not ?


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

[lldb-dev] lldb on linux translates keypresses into unicode escapes

[Nat! via lldb-dev]

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 seen this before and has an idea how to fix this ?

Ciao
   Nat!


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

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

[Nat! via lldb-dev]

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
Nat!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

[Nat! via lldb-dev]

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
> handle the lookup of some field in a struct. Of course, this is
> assuming you are actually able to modify the compiler.
> 
> (disclaimer: I know next to nothing, when it comes to objc)
> 

That would probably be ideal. I have to see if I can do this. But my
metaABI is somewhat "hacked" into clang. So I am not saying it wouldn't
work, but I suspect it won't, as I am relying on existing clang code.

Ciao
   Nat!

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

[lldb-dev] A bit of extra-polish for my lldb plugin

[Nat! via lldb-dev]

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=0x7fff5fbff948) at multiple.m:15
   12char:(char) c
   13   float:(float) d
   14   {
   15  printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
-> 16   }
   17   
   18   @end
(lldb) p *_param
(p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
18.475)
```

You can see that the parameter values `a,b,c,d` are actually fields of
a struct parameter `_param`. `_param` uniformly appears as the third
parameter after `self` and `_cmd`. `p _param->a` works of course, but it
would be nice to be able to say 'p a', since in the source code one sees
only `a`. `_param` is more or less an implementation detail.

A clue how to achieve this, would be very much appreciated.

Ciao
   Nat!


[*] except, if it's a picture of thousand words :)

https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to prolong or duplicate a backstop breakpoint

[Nat! via lldb-dev]

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

[lldb-dev] How to prolong or duplicate a backstop breakpoint

[Nat! via 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 intermediate function. I
think this is, because I am not using trampolines (jumps) but plain C
functions.

When I turn on `log enabled lldb step` and watch what is hapenning  when
lldb steps through to -[foo class] (0x00010df0)
I can see this at one point in time on the thread plan stack:

```
  thread #1: tid = 0x8c74:
Active plan stack:
  Element 0: Base thread plan.
  Element 1: Stepping in through line class.m:44 using
ranges:[0x00010ea6-0x00010ebf).

  Element 2: Stepping through trampoline code from:
0x00010f42 with backstop breakpoint ID: -5 at address:
0x00010ebf

  Element 3: Stepping to implementation of ObjC method - obj:
0x11158, isa: 0x11130, sel: 0x7fff91f58a12
  Element 4: Run to address: 0x00010df0 using breakpoint: -9 -
```

There is a backstop breakpoint -5 at the address 0x00010ebf.
Fine. But then, when the start of my method -[foo class]  is reached,
the trampoline handler is popped and the breakpoint vanishes!. I need to
somehow "prolong" this backstop breakpoint.

If I were to add a breakpoint to the return address
(0x00010f42), I would lose the functionality, that "continue"
just continues w/o breaking on the backstop. So maybe I need to push
something ahead of the "step through" on the ThreadPlan stack but what ?

Ciao
   Nat!

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

Re: [lldb-dev] What is the concept behind AppleObjCTrampolineHandler::AppleObjCVTables ?

[Nat! via lldb-dev]

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!

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

[lldb-dev] What is the concept behind AppleObjCTrampolineHandler::AppleObjCVTables ?

[Nat! via lldb-dev]

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/objc4-437/runtime/objc-gdb.h


But in the actual runtime, ojc4-709, I find only a reference to it in 
`libobjc.order`.


```
libobjc.order
32:_gdb_objc_trampolines_changed
```

So I'd like to know if AppleObjCVTables is just used for these 
apparently obsolete objc_trampoline_header structures, or if there is 
more to it.


Ciao
   Nat!





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

[lldb-dev] lock() fails on my lldb::Type

[Nat! via lldb-dev]

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_class_cache`. 
Which is no good for me.


I try to fix this by looking through my DeclVendor, check if a class is 
defined in the runtime, and if yes I create a substitute lldb::Type.


``
   DeclVendor *vendor = GetDeclVendor();
   if( vendor)
   {
 std::vector decls;
 uint32_t  count = vendor->FindDecls( name, false, 1, decls);

 if( count)
 {
 if (clang::ObjCInterfaceDecl *interface_decl = 
llvm::dyn_cast( decls[ 0]))

 {
CompilerType compiler_type = 
ClangASTContext::GetTypeForDecl(interface_decl);

Declaration whatever;
Type   *type = new Type(  LLDB_INVALID_UID,
  NULL,
  name,
  1024, // just ... 



  NULL,
  LLDB_INVALID_UID,
  Type::eEncodingIsUID,
  whatever,
  compiler_type,
  Type::eResolveStateFull);
 TypeSP  p_type( type);

 p_type->SetIsCompleteObjCClass( true);
 m_complete_class_cache[ name] = p_type;

 return( p_type);
  }
   }
   }
}
m_negative_complete_class_cache.insert(name);
return TypeSP();
}
```

This doesn't fail outright, but the next time LookupInCompleteClassCache 
is called, the codes does this `lock()` with my cached type and fails:


```
   TypeSP complete_type_sp (complete_class_iter->second.lock());

if (complete_type_sp)
return complete_type_sp;
```

Then the code will create a duplicate type. So what do I have to do, so 
that my lldb::Type doesn't return NULL when lock() is called ?


Nat!

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

[lldb-dev] Trying to understand AppleObjCRuntimeV1::CreateObjectChecker

[Nat! via lldb-dev]

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 fly, 
It seems to do nothing. I guess the code has a chance of crashing, if 
the parameter is not really an object. The debugger could notice that 
and figure out, that it's not an object. But guessing is not knowing... :)


Ciao
  Nat!


```
struct BufStruct {
char contents[2048];
};

UtilityFunction *
AppleObjCRuntimeV1::CreateObjectChecker(const char *name)
{
std::unique_ptr buf(new BufStruct);

assert(snprintf(&buf->contents[0], sizeof(buf->contents),
"struct __objc_class 
 \n"
"{ 
 \n"
"   struct __objc_class *isa; 
 \n"
"   struct __objc_class *super_class; 
 \n"
"   const char *name; 
 \n"
"   // rest of struct elided because unused 
 \n"
"}; 
 \n"
" 
 \n"
"struct __objc_object 
 \n"
"{ 
 \n"
"   struct __objc_class *isa; 
 \n"
"}; 
 \n"
" 
 \n"
"extern \"C\" void 
 \n"
"%s(void *$__lldb_arg_obj, void 
*$__lldb_arg_selector)  \n"
"{ 
 \n"
"   struct __objc_object *obj = (struct 
__objc_object*)$__lldb_arg_obj; \n"
"   (int)strlen(obj->isa->name); 
 \n"
"} 
 \n",

name) < (int)sizeof(buf->contents));

Error error;
return GetTargetRef().GetUtilityFunctionForLanguage(buf->contents, 
eLanguageTypeObjC, name, error);

}
```

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