gdb/python: fix gdb.Block repr output

gdb/python: fix gdb.Block repr output

I noticed that when printing a gdb.Block object in Python, I would
occasionally get corrupted, nonsensical output, like this:

  <gdb.Block <anonymous> {intintyinty_1inty_3inty_5... (-5 more symbols)}>

The symbol list is missing commas, it should be:

  int, inty, inty_1, inty_3, inty_5, ...

And the '-5 more symbols' is clearly not right.

The problem is in python/py-block.c, we use this line to calculate the
number of symbols in a block:

  const int len = mdict_size (block->multidict ());

Then we loop over the symbols in the block like this:

  for (struct symbol *symbol : block_iterator_range (block))
    ...

The problem here is that 'block_iterator_range (block)' can loop over
more symbols than just those within 'block'.  For global and static
blocks, block_iterator_range() takes into account included CUs; and so
can step through multiple global or static blocks.  See
block_iterator_step and find_iterator_compunit_symtab in block.c for
more details.

In contrast, 'mdict_size (block->multidict ())' only counts the
symbols contained within 'block' itself.

I could fix this by either fixing LEN, or by only iterating over the
symbols within 'block'.

I assume that printing a gdb.Block object is used mostly for debug
purposes; the output isn't really user friendly, so I cannot imagine a
user script that is relying on printing a gdb.Block as a way to inform
the user about blocks in their program.  As such, I think it makes
more sense if the symbols listed are restricted to those strictly held
within the block.

And so, instead of block_iterator_range, I've switched to iterating
over the multidict symbols.  Now the calculated LEN will match the
number of symbols being printed, which fixes the output seen above.
However, as we're now only printing symbols that are within the block
being examined, the output above becomes:

  <gdb.Block <anonymous> {}>

All the symbols that GDB previously tried to print, are coming from an
included CU.

For testing, I've made use of an existing DWARF test that tests
DW_AT_import.  In the wild I saw this in an inferior that used
multiple shared libraries that has their debug information stored in a
separate debug file, and then parts of that debug information was
combined into a third separate file using the DWZ tool.  I made a few
attempts to craft a simpler reproducer, but failed.  In the end it was
easier to just use a DWARF assembler test to reproduce the issue.

I have added some more typedef symbols into the DWARF test, I don't
believe that this will impact the existing test, but makes the
corrupted output more obvious.

Approved-By: Tom Tromey <tom@tromey.com>