Some containers not being recognized.

[Labdabeta]

While using these pretty printers to debug a compiler I am writing I realized that many containers weren't pretty printed. In particular I was able to write:

(gdb) ptype macros
type = new ada.finalization.controlled with record
    ht: preprocessing.macro_maps.ht_types.hash_table_type;
end record
(gdb) p macros
$6 = (ht => (buckets => 0x7ffff0000b68, length => 7, tc => (busy => 0, lock => 0)))
(gdb) p next.data.value
$7 = Unbounded_String (")")
(gdb) info pretty-printer 
global pretty-printers:
  builtin
    mpx_bound128
  objfile /home/louis/projects/lab/lcc pretty-printers:
  gnat-runtime
    Doubly_Linked_List
    Doubly_Linked_List_Cursor
    Hashed_Map
    Hashed_Set
    Ordered_Map
    Ordered_Map_Cursor
    Ordered_Map_Cursor
    Ordered_Set
    Ordered_Set_Cursor
    Ordered_Set_Cursor
    Unbounded_String
    Vector
    Vector_Cursor
    access String

Which is unusual because macros is a hash_map and should be pretty printed, but isn't. Meanwhile next data value is an unbounded string and is pretty printed as expected.

Unfortunately I have not yet come up with a minimal example that causes this, but as soon as I do I will post it here as well. I suspect this is some bug about nesting of child packages with new names, as the containers in question have keys and elements of compound types and are declared within child packages.

[pmderodat]

Hello,
Thank you for reporting this. Indeed, some reproducer would help investigating this problem: for now, the testcases we have show that the pretty printer for hashed maps works well, at least for simple cases. By the way, what version of GNAT do you use (you can check the output of the gcc -v command). We’ll wait for your minimal example. :-)

[Labdabeta]

I'm still trying to find a reproducible example with little success. If I can't find one in a few days I'll just push the repo for my current project to github and expose a not so minimal reproducible example. Meanwhile the output of my gcc -v command is:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.1 20171224 (GCC) 

[Labdabeta]

I finally trimmed my project to under 50 lines of code that will still cause the error. I am not sure if all aspects of the setup are necessary, but at least it is reproducible:

main.adb:

with Ada.Text_IO;
with Pretty_Testing;

procedure Main is
    Pretty_Tester : Pretty_Testing.Pretty_Tester;
begin
    Pretty_Tester.Test;
end Main;

pp_test.gpr:

project PP_Test is
    for Source_Dirs use ("pp",".");
    for Object_Dir use "build";
    for Exec_Dir use "../../";
    for Main use ("main.adb");

    package Compiler is
        for Default_Switches ("Ada") use
            ("-g");
    end Compiler;

    package Binder is
        for Default_Switches ("Ada") use ("-u100", "-g");
    end Binder;

    package Builder is
        for Executable ("main.adb") use "oops";
    end Builder;
end PP_Test;

build/: An empty directory

pp/pretty_testing.ads:

package Pretty_Testing is
    task type Pretty_Tester is
        entry Test;
    end Pretty_Tester;
end Pretty_Testing;

pp/pretty_testing.adb:

with Ada.Text_IO;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Containers.Vectors;
with Ada.Containers.Hashed_Maps;
with Ada.Strings.Unbounded.Hash;

package body Pretty_Testing is
    package Test_Vectors is new Ada.Containers.Vectors (
        Index_Type => Positive, Element_Type => Integer);

    package Test_Maps is new Ada.Containers.Hashed_Maps (
        Key_Type => Unbounded_String, Element_Type => Test_Vectors.Vector,
        Hash => Ada.Strings.Unbounded.Hash,
        Equivalent_Keys => "=",
        "=" => Test_Vectors."=");

    task body Pretty_Tester is
        Problem : Test_Maps.Map;
    begin
        Problem.Insert (
            To_Unbounded_String ("test"),
            Test_Vectors.Empty_Vector);
        loop
            select
                accept Test;
            or
                terminate;
            end select;
        end loop;
    end Pretty_Tester;
end Pretty_Testing;

Put all of these in at least 2 levels of nested directories, then cd to the directory with the gpr configuration file, run gprbuild -P pp_test.gpr then cd ../.. and gdb ./oops. Break at pretty_testing.adb:23 and then print problem and it should show something along the lines of $1 = (ht => (buckets => 0x7ffff0000b58, length => 1, tc => (busy => 0, lock => 0))) even though problem is a hashed map.

I'm not sure if its the task causing issues, or the weird file nesting, or maybe the fact that the executable is in a different directory, but this causes the problem regularly for me.

[pmderodat]

Ah, I see, thanks. It seems that just having GCC FSF 7.2.1 is enough to break pretty-printers for hashed containers. This is unfortunately not a surprise: as we say in the README:

Note that these helpers are intrinsically tied to specific runtime implemenations. For instance, when the implementation of a container is changed, the corresponding pretty-printer must be updated. For now, the master branch of this repository is synchronized with GNAT Pro's development branch.

This describes the situation we have here: a “recent” commit in GNAT changed the implementation of containers, requiring a pretty-printer update, breaking compatibility with older toolchains. I’m not sure yet how we should make the GDB scripts support multiple GCC versions (and properly test that support!). Note that the corresponding GNAT commit was already ported at the FSF (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c80119a08770ac28848c33525a5b343b681495d3), so all will work well with the upcoming GCC 8 release.

In the meantime, this temporary branch should work for you. Can you confirm?