[Lldb-commits] [PATCH] D117707: [lldb] [Platform] Support synthesizing siginfo_t

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

In D117707#3269214 <https://reviews.llvm.org/D117707#3269214>, @labath wrote:

> Adding Alex for the plugin dependency aspect. I don't think this dep is wrong (it's pretty hard to pretend we don't at least have a C language), but he may want to say something about this.

I think we need to have a way to express types that the basic system uses so we can present them in a structured way to users.  Formally, you could express this by saying that we need a "platform language" reflecting how that platform vends it's API's at the lowest level.  This would have been Pascal for classic MacOS way back in the day, and maybe Lisp for Lisp machines.  But IRL all the platforms we are likely to deal with express their lowest level system API's in C, so it seems okay to have that be an implicit assumption till we come across a system that we want to support and for which C isn't one of the low level system languages.

> The patch itself is somewhat repetitive, but otherwise seems ok.
>
> I am a bit curious about the `__lldb` prefix. I'm wondering if there's a way to avoid having it, while still maintaining isolation from any type with the same name coming from the debug info. I'm thinking about putting it in some kind of an anonymous namespace or something... Does anyone know if that works?

This will be the actual type of an SBValue, as is the case in other instances where we've made up types, so users will see this type if they look closely.  So it should be clear from the name that this is just an artificial type lldb made up.  `__lldb_whatever` expresses that pretty clearly, but I'm worried some reasonable looking name in an anonymous namespace would send users off on a wild goose chase.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117707/new/

https://reviews.llvm.org/D117707