I think that's orthogonal to the point, which was that a rnglist is
meant to describe a pc range, not a data range.
BTW, I don't think you need to create the vtable on the fly in that
case. The Pkg.Print function will need a static link, but the vtable
doesn't need to encode that. I just checked our Ada compiler. We
stopped development on this compiler after Ada 95, but the only change I
had to make to your example to make it Ada 95-friendly, was the call to
Print: Pkg.Print(Object). (They were avoiding the Object.Function
syntax in Ada 95, but I assume they relented and added some syntactic
sugar in Ada 2005 or 2012.) Our compiler does indeed generate a static
vtable.
But if GNAT is generating the vtable at run-time, possibly even on the
stack (maybe there's some other, more compelling, reason?), then we need
to make sure the proposal isn't assuming a static location.
On 5/7/25 07:07, Pierre-Marie de Rodat wrote:
> Hello,
>
> On Wed, May 7, 2025 at 2:49 PM Todd Allen via Dwarf-discuss
> <dwarf-discuss@lists.dwarfstd.org> wrote:
>> In 250506.2, the use of a rnglist is throwing me. I would expect the
>> lifetime of a vtable to be the whole program. Or did you envision the
>> rnglist to be the range of data/rodata addresses of the vtable object? 2.17
>> clarifies that they're code addresses (i.e. text), though.
>>
>> We did have a discussion sometime in the last year about describing
>> data/rodata address ranges, but that was in .debug_aranges (RIP). And,
>> IIRC, no actual compiler was generating data/rodata address there either.
> If it helps the design: there are languages where vtables are not
> necessarily statically allocated. Here is a small Ada example,
> involving a tagged type (equivalent to a C++ class) nested in a
> procedure, and with a primitive (C++ method) that actually has
> up-level references to the procedure locals (so the vtable is actually
> tied to the current stack frame):
>
> 1 with Ada.Text_IO; use Ada.Text_IO;
> 2
> 3 procedure Main is
> 4 Msg : constant String := "Hello world";
> 5
> 6 package Pkg is
> 7 type T is tagged null record;
> 8 procedure Print (Self : T);
> 9 end Pkg;
> 10
> 11 package body Pkg is
> 12 procedure Print (Self : T) is
> 13 begin
> 14 Put_Line (Msg);
> 15 end Print;
> 16 end Pkg;
> 17
> 18 Object : Pkg.T;
> 19 begin
> 20 Object.Print;
> 21 end Main;
>
> GDB allows us to observe where the vtable for T is stored (tested on a
> x86_64-linux machine):
>
> $ gdb ./main
> (gdb) b main.adb:20
> Breakpoint 1 at 0x6ae9: file main.adb, line 20.
> (gdb) r
> […]
> Breakpoint 1, main () at main.adb:20
> 20 Object.Print;
> (gdb) set lang c
> Warning: the current language does not match this frame.
> (gdb) print object
> $1 = {_tag = 0x7fffffffda30}
> (gdb) p $rsp
> $2 = (void *) 0x7fffffffd7d0
> (gdb) p $rbp
> $3 = (void *) 0x7fffffffda70
>
> “_tag” is an artificial component for the record T that GCC
> (currently) generates in the debug info to materialize the vtable: it
> points to a structure that is in the current stack frame (between $rsp
> and $rbp).
>
> --
> Pierre-Marie de Rodat <dero...@adacore.com>
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
