Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [committed][gdb/symtab] Fix CU list in .debug_names for dummy CUs
Date: Tue, 14 Sep 2021 13:01:59 +0200	[thread overview]
Message-ID: <7964426a-5018-c32f-ef71-880d22c8c69f@suse.de> (raw)
In-Reply-To: <20210826115901.GA22856@delia>

On 8/26/21 1:59 PM, Tom de Vries wrote:
> Hi,
> 
> With current trunk and target board cc-with-debug-names we have:
> ...
> (gdb) file dw2-ranges-psym^M
> Reading symbols from dw2-ranges-psym...^M
> warning: Section .debug_names in dw2-ranges-psym has abbreviation_table of \
>   size 1 vs. written as 28, ignoring .debug_names.^M
> (gdb) set complaints 0^M
> (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints
> ...
> 
> The executable has 8 compilation units:
> ...
> $ readelf -wi dw2-ranges-psym | grep @
>   Compilation Unit @ offset 0x0:
>   Compilation Unit @ offset 0x2e:
>   Compilation Unit @ offset 0xa5:
>   Compilation Unit @ offset 0xc7:
>   Compilation Unit @ offset 0xd2:
>   Compilation Unit @ offset 0x145:
>   Compilation Unit @ offset 0x150:
>   Compilation Unit @ offset 0x308:
> ...
> of which the ones at 0xc7 and 0x145 are dummy CUs (that is, they do not
> contain a single DIE), which were added by recent commit 5ef670d81fd
> "[gdb/testsuite] Add dummy start and end CUs in dwarf assembly".
> 
> The .debug_names section contains this CU table:
> ...
> [  0] 0x0
> [  1] 0x2e
> [  2] 0xa5
> [  3] 0xd2
> [  4] 0x150
> [  5] 0x308
> [  6] 0x1
> [  7] 0x0
> ...
> The last two entries are incorrect, and the entries for the dummy CUs are
> missing.
> 
> The last two entries are incorrect because here in write_debug_names we write
> the dimension of the CU list as 8:
> ...
>   /* comp_unit_count - The number of CUs in the CU list.  */
>   header.append_uint (4, dwarf5_byte_order,
>                      per_objfile->per_bfd->all_comp_units.size ()
>                      - per_objfile->per_bfd->tu_stats.nr_tus);
> ...
> while the actual dimension of the CU list is 6.
> 
> The discrepancy is caused by this code which skips the dummy CUs:
> ...
>   for (int i = 0; i < per_objfile->per_bfd->all_comp_units.size (); ++i)
>     {
>       ...
>       /* CU of a shared file from 'dwz -m' may be unused by this main
>         file.  It may be referenced from a local scope but in such
>         case it does not need to be present in .debug_names.  */
>       if (psymtab == NULL)
>        continue;
> ...
> because they have a null partial symtab.
> 
> We can fix this by writing the actual dimension of the CU list, but that still
> leaves the dummy CUs out of the CU list.  The purpose of having these is to
> delimit the end of preceding CUs.
> 
> So, fix this by:
> - removing the code that skips the dummy CUs (note that the same change
>   was done for .gdb_index in commit efba5c2319d '[gdb/symtab] Handle PU
>   without import in "save gdb-index"'.
> - verifying that all units are represented in the CU/TU lists
> - using the actual CU list size when writing the dimension of the CU list
>   (and likewise for the TU list).
> 
> Tested on x86_64-linux with native and target board cc-with-debug-names.
> 
> Any comments?
> 

I've committed this.

Thanks,
- Tom

> [gdb/symtab] Fix CU list in .debug_names for dummy CUs
> 
> ---
>  gdb/dwarf2/index-write.c | 20 ++++++++------------
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/gdb/dwarf2/index-write.c b/gdb/dwarf2/index-write.c
> index 4e00c716d91..0fe2bc4dd05 100644
> --- a/gdb/dwarf2/index-write.c
> +++ b/gdb/dwarf2/index-write.c
> @@ -1428,16 +1428,10 @@ write_debug_names (dwarf2_per_objfile *per_objfile,
>  	= per_objfile->per_bfd->all_comp_units[i].get ();
>        partial_symtab *psymtab = per_cu->v.psymtab;
>  
> -      /* CU of a shared file from 'dwz -m' may be unused by this main
> -	 file.  It may be referenced from a local scope but in such
> -	 case it does not need to be present in .debug_names.  */
> -      if (psymtab == NULL)
> -	continue;
> -
>        int &this_counter = per_cu->is_debug_types ? types_counter : counter;
>        data_buf &this_list = per_cu->is_debug_types ? types_cu_list : cu_list;
>  
> -      if (psymtab->user == NULL)
> +      if (psymtab != nullptr && psymtab->user == nullptr)
>  	nametable.recursively_write_psymbols (objfile, psymtab, psyms_seen,
>  					      this_counter);
>  
> @@ -1447,6 +1441,11 @@ write_debug_names (dwarf2_per_objfile *per_objfile,
>        ++this_counter;
>      }
>  
> +   /* Verify that all units are represented.  */
> +  gdb_assert (counter == (per_objfile->per_bfd->all_comp_units.size ()
> +			  - per_objfile->per_bfd->tu_stats.nr_tus));
> +  gdb_assert (types_counter == per_objfile->per_bfd->tu_stats.nr_tus);
> +
>    nametable.build ();
>  
>    /* No addr_vec - DWARF-5 uses .debug_aranges generated by GCC.  */
> @@ -1481,14 +1480,11 @@ write_debug_names (dwarf2_per_objfile *per_objfile,
>    header.append_uint (2, dwarf5_byte_order, 0);
>  
>    /* comp_unit_count - The number of CUs in the CU list.  */
> -  header.append_uint (4, dwarf5_byte_order,
> -		      per_objfile->per_bfd->all_comp_units.size ()
> -		      - per_objfile->per_bfd->tu_stats.nr_tus);
> +  header.append_uint (4, dwarf5_byte_order, counter);
>  
>    /* local_type_unit_count - The number of TUs in the local TU
>       list.  */
> -  header.append_uint (4, dwarf5_byte_order,
> -		      per_objfile->per_bfd->tu_stats.nr_tus);
> +  header.append_uint (4, dwarf5_byte_order, types_counter);
>  
>    /* foreign_type_unit_count - The number of TUs in the foreign TU
>       list.  */
> 

      reply	other threads:[~2021-09-14 11:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 11:59 [PATCH][gdb/symtab] " Tom de Vries via Gdb-patches
2021-09-14 11:01 ` Tom de Vries via Gdb-patches [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7964426a-5018-c32f-ef71-880d22c8c69f@suse.de \
    --to=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox