This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] DWARF 5 support: Handle line table and file indexes
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Ali Tamur <tamur at google dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 21 Oct 2019 01:55:15 -0400
- Subject: Re: [PATCH] DWARF 5 support: Handle line table and file indexes
- Dkim-filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x9L5tGS3026769
- References: <99f8963b76221d747d0564919217a2eb@polymtl.ca> <20191018193116.57020-1-tamur@google.com>
On 2019-10-18 3:31 p.m., Ali Tamur wrote:
> I've done everything asked, except this bit:
>> I'd still suggest adding a gdb_assert to verify that in the case of
> DWARF <= 4, index should be > 0.
>
> This caused failure in multiple tests, I think the correct behaviour is to
> return nullptr when DWARF <= 4 and index = 0 (done).
Oh, right, requesting the entry 0 isn't invalid, it's just that it represents the
compilation directory, which is not explicitly represented. We indeed return
NULL at the moment when requesting index 0 (it underflows the unsigned variable),
so you are right that we should continue doing that.
> @@ -20651,12 +20689,11 @@ dwarf_decode_line_header (sect_offset sect_off, struct dwarf2_cu *cu)
> Returns NULL if FILE_INDEX should be ignored, i.e., it is pst->filename. */
>
> static const char *
> -psymtab_include_file_name (const struct line_header *lh, int file_index,
> +psymtab_include_file_name (const struct line_header *lh, const file_entry &fe,
> const struct partial_symtab *pst,
> const char *comp_dir,
> gdb::unique_xmalloc_ptr<char> *name_holder)
The comment above this function says:
Return the file name of the psymtab for included file FILE_INDEX
It would need to be updated.
> @@ -24190,6 +24221,14 @@ dwarf_alloc_die (struct dwarf2_cu *cu, int num_attrs)
>
> /* Macro support. */
>
> +static bool
> +is_valid_file_index (int file_index, struct line_header *lh)
> +{
> + if (lh->version >= 5)
> + return 0 <= file_index && file_index < lh->file_names_size ();
> + return 1 <= file_index && file_index <= lh->file_names_size ();
> +}
I think it would make sense if this was a method of line_header, since it's related to
the line_header::file_name_at method.
Simon