[Dwarf-discuss] Additional values for DW_AT_accessibility

[Ben Woodard]

On 9/24/26 5:18 PM, Cary Coutant via Dwarf-discuss wrote:
>
>     Currently there are the values
>     DW_ACCESS_public DW_ACCESS_private DW_ACCESS_protected
>
>     FreePascal has more (list at the end of mail)
>     Could those please be added?
>
>     https://www.freepascal.org/docs-html/ref/refse35.html
>     > Private
>     >   All fields and methods that are in a private block, can only be
>     > accessed in the module (i. e. unit) that contains the class
>     definition.
>     >   They can be accessed from     inside the classes’ methods or from
>     > outside them (e. g. from other classes’ methods)
>     > Strict Private
>     >   All fields and methods that are in a strict private block, can
>     only
>     > be accessed from methods of the class itself. Other classes or
>     > descendent classes (even in the   same unit) cannot access strict
>     > private members.
>     > Protected
>     >   Is the same as Private, except that the members of a Protected
>     > section are also accessible to descendent types, even if they are
>     > implemented in other   modules.
>     > Strict Protected
>     >   Is the same as Protected, except that the members of a
>     > Protected section are also accessible to other classes
>     implemented in
>     > the same unit. Strict protected   members are only visible to
>     > descendent classes, not to other classes in the same unit.
>     > Public
>     >   sections are always accessible.
>     > Published
>     >   From a language perspective, this is the same as a Public
>     section,
>     > but the compiler generates also type information that is needed for
>     > automatic streaming of   these classes if the compiler is in the
>     {$M+}
>     > state. Fields defined in a published section must be of class type.
>     > Array properties cannot be in a published section.
>
>
> 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.

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.

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 is a tough question. So what do we want to do?

-ben

> I don't see a need to represent "published" as distinct from "public".
>
> While we're at it, I see the need to add more descriptive text in the 
> spec to make these accessibility attributes more broadly applicable 
> across languages.
>
> -cary
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20260925/1199973a/attachment.htm>