Backtrace as assert:
...
#8  0x0000000000b0401b in internal_error (file=0xb4c4a8 "/home/vries/gdb_versions/devel/src/gdb/gdbtypes.h", line=526, 
    fmt=0xb4c44a "%s: Assertion `%s' failed.") at /home/vries/gdb_versions/devel/src/gdbsupport/errors.cc:55
#9  0x0000000000436e4b in dynamic_prop::const_val (this=0x137a0f0) at /home/vries/gdb_versions/devel/src/gdb/gdbtypes.h:526
#10 0x00000000004198ec in ada_discrete_type_high_bound (type=0x137a060) at /home/vries/gdb_versions/devel/src/gdb/ada-lang.c:728
#11 0x0000000000448aec in print_range (type=0x1388110, stream=0x121d1f0, bounds_prefered_p=1)
    at /home/vries/gdb_versions/devel/src/gdb/ada-typeprint.c:160
#12 0x000000000044ae49 in ada_print_type (type0=0x1388110, 
    varstring=0x1379f40 "<ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1___XDL_1>", stream=0x121d1f0, 
    show=1, level=5, flags=0xc53620 <type_print_raw_options>) at /home/vries/gdb_versions/devel/src/gdb/ada-typeprint.c:1041
#13 0x00000000004385cb in ada_language::print_type (this=0xff4d60 <ada_language_defn>, type=0x1388110, 
    varstring=0x1379f40 "<ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1___XDL_1>", stream=0x121d1f0, 
    show=1, level=5, flags=0xc53620 <type_print_raw_options>) at /home/vries/gdb_versions/devel/src/gdb/ada-lang.c:13877
#14 0x00000000008c071a in print_symbol (gdbarch=0x12314a0, symbol=0x1388210, depth=5, outfile=0x121d1f0)
    at /home/vries/gdb_versions/devel/src/gdb/symmisc.c:584
#15 0x00000000008bfa1c in dump_symtab_1 (symtab=0x1229aa0, outfile=0x121d1f0) at /home/vries/gdb_versions/devel/src/gdb/symmisc.c:353
#16 0x00000000008bfc23 in dump_symtab (symtab=0x1229aa0, outfile=0x121d1f0) at /home/vries/gdb_versions/devel/src/gdb/symmisc.c:411
#17 0x00000000008c02ea in maintenance_print_symbols (args=0x0, from_tty=1) at /home/vries/gdb_versions/devel/src/gdb/symmisc.c:520
#18 0x0000000000501d16 in do_const_cfunc (c=0x1161690, args=0x0, from_tty=1) at /home/vries/gdb_versions/devel/src/gdb/cli/cli-decode.c:95
#19 0x00000000005053a0 in cmd_func (cmd=0x1161690, args=0x0, from_tty=1) at /home/vries/gdb_versions/devel/src/gdb/cli/cli-decode.c:2181
#20 0x000000000091a0c3 in execute_command (p=0x7fffffffe232 "", from_tty=1) at /home/vries/gdb_versions/devel/src/gdb/top.c:668
#21 0x0000000000737cb4 in catch_command_errors (command=0x919b4a <execute_command(char const*, int)>, arg=0x7fffffffe21f "maint print symbols", from_tty=1) at /home/vries/gdb_versions/devel/src/gdb/main.c:457
#22 0x0000000000739087 in captured_main_1 (context=0x7fffffffdb50) at /home/vries/gdb_versions/devel/src/gdb/main.c:1218
#23 0x0000000000739277 in captured_main (data=0x7fffffffdb50) at /home/vries/gdb_versions/devel/src/gdb/main.c:1243
#24 0x00000000007392e2 in gdb_main (args=0x7fffffffdb50) at /home/vries/gdb_versions/devel/src/gdb/main.c:1268
#25 0x0000000000411b39 in main (argc=13, argv=0x7fffffffdc68) at /home/vries/gdb_versions/devel/src/gdb/gdb.c:32
...

Reason for assert:
...
(gdb) 
#9  0x0000000000436e4b in dynamic_prop::const_val (this=0x137a0f0) at /home/vries/gdb_versions/devel/src/gdb/gdbtypes.h:526
526         gdb_assert (m_kind == PROP_CONST);
(gdb) p m_kind
$1 = PROP_UNDEFINED
...

Created attachment 12696 [details]
foo exec

Ok, I was able to reproduce it, but using the Ada distribution from AdaCore, which comes with debug info for the standard library (not sure if that's the right terminology).

Proposed patch: https://sourceware.org/pipermail/gdb-patches/2020-July/170408.html

The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d1fd641e0b48e75401311528450eb1ddfb3a1fa0

commit d1fd641e0b48e75401311528450eb1ddfb3a1fa0
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Jul 21 15:12:56 2020 -0400

    gdb: handle undefined properties in ada_discrete_type_{low,high}_bound
    
    This patch fixes a failure in test `gdb.ada/access_to_packed_array.exp`.
    The failure was introduced by 8c2e4e0689ea24 ("gdb: add accessors to
    struct dynamic_prop"), but I think it in fact exposed a latent buglet.
    
    Note that to reproduce it, I had to use AdaCore's Ada "distribution"
    [1].  The one that comes with my distro doesn't have debug info for the
    standard library stuff, so the bug wouldn't trigger.
    
    The bug is that while executing the `maint print symbols` command, we
    are accessing the value of a range type's high bound dynamic prop as a
    "const" value (PROP_CONST), when it is actually undefined
    (PROP_UNDEFINED).  It results in this failed assertion:
    
        /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
    
    `ada_discrete_type_high_bound` calls `resolve_dynamic_type`, which
    eventually calls `resolve_dynamic_range`.  This one is responsible for
    evaluating a range type's dynamic bounds in the current context and
    returning static values.  It returns a new range type with these static
    bounds.
    
    The resulting bounds are typically properties of the PROP_CONST kind.
    But when it's not possible to evaluate the properties, the properties
    are PROP_UNDEFINED.  In the case we are looking at, it's not possible to
    evaluate the dynamic high bound, which is of type PROP_LOCLIST.  It
    would require a target with registers and a frame, but we run `maint
    print symbols` without a live process.
    
    `ada_discrete_type_high_bound` then accesses the high bound
    unconditionally as a const value, which triggers the assert.
    
    Note that the previous code in resolve_dynamic_range (before commit
    8c2e4e0689ea24) did this:
    
        prop = &TYPE_RANGE_DATA (dyn_range_type)->high;
        if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
          {
            high_bound.kind = PROP_CONST;
            high_bound.data.const_val = value;
    
            if (TYPE_RANGE_DATA (dyn_range_type)->flag_upper_bound_is_count)
            high_bound.data.const_val
              = low_bound.data.const_val + high_bound.data.const_val - 1;
          }
        else
          {
            high_bound.kind = PROP_UNDEFINED;
            high_bound.data.const_val = 0;
          }
    
    That did not really made sense, setting the kind to `PROP_UNDEFINED` but
    also setting the `const_val` field.  The `const_val` field is only
    meaningful if the kind if `PROP_CONST`.  The new code
    (post-8c2e4e0689ea24) simply calls `set_undefined ()`.
    
    Fix this by making the caller, `ada_discrete_type_high_bound`, consider
    that a range high bound could be of kind `PROP_UNDEFINED`, and return
    0 in this case.  I made the same change in ada_discrete_type_low_bound.
    I didn't encounter a problem with this function, but the same could in
    theory happen there.
    
    Returning 0 here is kind of a lie, but the goal here is just to restore
    the behavior of pre-8c2e4e0689ea24.
    
    The output of `maint print symbols` is:
    
         typedef <ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
         record
             ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
         end record;
    
    Instead of `1 .. 0`, which does not make sense, we could say something
    like `1 .. <dynamic>`.  But that would require more changes than I'm
    willing to do at the moment.
    
    [1] https://www.adacore.com/download
    
    gdb/ChangeLog:
    
            PR ada/26235
            * gdbtypes.c (ada_discrete_type_low_bound,
            ada_discrete_type_high_bound): Handle undefined bounds.
    
    Change-Id: Ia12167e61ef030941c0790f83294f3418e6a7c12

Fixed.

(In reply to Simon Marchi from comment #4)
> Ok, I was able to reproduce it, but using the Ada distribution from AdaCore,
> which comes with debug info for the standard library (not sure if that's the
> right terminology).

Hi Simon,

For my understanding, does this mean that you where not able to reproduce this with the exec I attached?  If so, what problem did you ran into?  Did it just not reproduce or were there other issues?

(In reply to Tom de Vries from comment #8)
> Hi Simon,
> 
> For my understanding, does this mean that you where not able to reproduce
> this with the exec I attached?  If so, what problem did you ran into?  Did
> it just not reproduce or were there other issues?

I just tried it, it does reproduce with your binary.  Seeing the timestamps of the messages, maybe I started working on it before you uploaded the binary, or I just didn't see it.

(In reply to Simon Marchi from comment #9)
> (In reply to Tom de Vries from comment #8)
> > Hi Simon,
> > 
> > For my understanding, does this mean that you where not able to reproduce
> > this with the exec I attached?  If so, what problem did you ran into?  Did
> > it just not reproduce or were there other issues?
> 
> I just tried it, it does reproduce with your binary.  Seeing the timestamps
> of the messages, maybe I started working on it before you uploaded the
> binary, or I just didn't see it.

Ack, thanks, then I misinterpreted this, and consequently didn't attach anything in PR26318.  I'll try to make sure it's there next time :)