[Dwarf-discuss] Additional values for DW_AT_accessibility

[Ben Woodard]

Cary,

it is comments like this which push me back toward the notion that the
semantics of what a accessibility means is not a universal concept that can
be captured within DWARF. It is contained within the language itself and is
an agreement between the producer and the consumer. DWARF just has to
convey, opaquely, the information from producer to consumer. I think this
how it is going to have to be because there are so many nuances in the
world of computer languages, that we cannot capture those if we try to give
universal semantic meaning to them.

With that being the case, I think that my write up of the proposal is as it
should be, We add 3 new accessibility specifications. It is up to Martin
and other implementers of FreePascal in his compiler and the consumer to
map those accessibility attributes to the source language keywords in their
producer and consumer. A direct mapping of private to DW_ACCESS_private
makes sense.

I think that the best that we can really do is give a suggested semantic
meaning to DW_ACCESS_private and protected referencing C++. Then FreePascal
and other can map the keyword "strict private" to DW_ACCESS_private and
then the proposal would have to be changed to add DW_ACCESS_module_private
and protected as you suggested.

I'm fine going either way. It is an epistemology, question and I just think
language specific relative truth is going to be the best that we are ever
going to achieve.

-ben

On Mon, Sep 28, 2026 at 2:24 AM Martin via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> On 25/09/2026 19:12, Ben Woodard via Dwarf-discuss wrote:
> >
> > 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.
> >
> Just to add some info, in case it may help with that decision.
>
> There likely will be some need of knowing the language to get the
> correct mapping.
>
> E.g. Delphi/FreePascal has "type/class helpers". Those are kind-of
> dataless classes, that can be used to
> - provide methods for another class
> - access protected (but not private) data across unit boundaries.
>
> They aren't an inherited class, more like a combination of interface and
> friend.
>
> But unlike (afaik?) a C++ friend, it only has (cross unit) access to
> protected, not private methods/data.
>
> So, if FPC where to declare them as friend, then the rules of what is
> accessible would be different from C++.
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20260928/a88970c7/attachment.htm>