[Dwarf-discuss] Additional values for DW_AT_accessibility

[Cary Coutant]

>
> From these descriptions, it looks to me like "strict private" and "strict
> protected" better match the existing meaning of DW_ACCESS_private and
> DW_ACCESS_protected, respectively (i.e., access is restricted to members of
> the class rather than the whole module, which is more like what these
> attributes mean for C++ code). If I'm understanding that correctly, would
> it be more accurate to add new enumerators for Pascal's plain "private" and
> "protected" attributes? Say, DW_ACCESS_module_private and
> DW_ACCESS_module_protected?
>
> I see what you mean Cary. At first I was confused. I believe that the
> referenced page on FreePascal.org has added some text that clarify the
> meaning since the time when I first put together the DWARF issue.
>
> In the context of freepascal "module" is roughly equivalent to the DWARF
> and ELF notion of a compilation unit. I did a bit of history research into
> the original module private and module protected specifications. How the
> concept of "private" vs. "strict private" and the similar protected
> accessibility declarations evolved is interesting. A module was basically
> assumed to be written by one author and thought to be a group of
> collaborating classes, That is why they had module wide access. However as
> the size of code increased and computers and compilers got faster the
> amount of code increased and so the notion that a module was the work of
> one author who understood all the relationships was increasingly not true.
> Consequently, they introduced the concept of "strict private" which is as
> you pointed out more akin to what we see in C++ and Ada.
>
Right. Wirth developed the concept of "module" (in designing Modula-2 as a
successor to Pascal), long before object-oriented concepts made it into
either language.

> However, one thing that I am not really clear about in DWARF is does
> DW_ACCESS_private have a specific semantic meaning independent of the
> language. If it does, then it is not specified. I can see it two different
> ways:
>
> DW_ACCESS_private has a semantic meaning in DWARF separate from the
> language. In that case because the FreePascal concept of "strict private"
> maps more closely to C++'s concept of "private" which is translated in
> DWARF into DW_ACCESS_private, "strict private" should map to
> DW_ACCESS_private.
>
> If we do this then I think we need to more clearly define what the implied
> semantics of the Accessibility codes mean and do it in such a way that it
> is independent of any language.
>
Yes, both Ron and I have noted that we should do this. Not just for
accessibility, but also for visibility and virtuality. We kind of punted on
those; for comparison, see how we described DW_AT_inline (4.3.8) and
identifier case (4.1.1, bullet #9).

> The other way that I can see it is DWARF acts as a mapping between the
> source language and the machine language and is interpreted by the consumer
> only in the context of the the language that the code was written in. In
> that case, it is the language that provides the semantic meaning of what
> the Accessibility Declaration means. That would lead to DW_ACCESS_private
> mapping to the (module) private keyword in the language. Strict private
> mapping to "DW_OP_strict_private"...
>
> This would require more of the consumers. For example: libabigail would
> have to understand the difference between "DW_ACCESS_private" as it applies
> to C++ and how it applies to FreePascal.
>
> I would say that I implicitly wrote
> https://dwarfstd.org/issues/260428.1.html assuming the latter but as I
> think about the complexity of retrofitting this kind of language dependent
> semantics into a tool like libabigail, I kind of prefer the former.
>
> The problem that I worry about is that there may not be perfect overlap
> between the semantics of different language's notion of what different
> accessibility declarations mean. This could lead to an explosion of
> DW_ACCESS_* qualifications to capture the nuances of different language's
> semantic differences in the meaning concepts like private protected or
> public. Even the two languages that we reference in the non-normative text
> leading into this section C++ and Ada have very different concepts of
> private and protected and you can't really assume that DW_ACCESS_private
> for Ada means the same thing as DW_ACCESS_private does to C++.
>
This has always been and will always be the question, won't it? The same
question applies to base types, visibility, virtuality, etc. The best we
can do is define what we need for each language, while making the concepts
as broadly applicable as possible without making them so broad as to be
meaningless. There will undoubtedly be cases where the language will imply
a subtle difference in meaning, but our best approach is to make the
attributes mean pretty much the same thing across languages. I don't
believe we've ever had (or should have) the goal of making the DWARF
spelling exactly match the language spelling. It matches C++ because that's
what we first introduced it for—if Pascal had come up at the time, we might
have spelled them DW_ACCESS_class_private/protected and
DW_ACCESS_module_private/protected.

-cary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20260925/3489b80b/attachment-0001.htm>