public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: nitachra <Nitika.Achra@amd.com>,
	gdb-patches@sourceware.org, tom@tromey.com
Cc: JiniSusan.George@amd.com
Subject: Re: [PATCH v2 2/2] DWARFv5: Fix for the filename complaint when printing macro
Date: Sat, 3 Oct 2020 22:32:48 -0400	[thread overview]
Message-ID: <31a228c0-3be7-0819-727c-3df78c5c46ee@simark.ca> (raw)
In-Reply-To: <20200810150628.1587-2-Nitika.Achra@amd.com>

On 2020-08-10 11:06 a.m., nitachra wrote:
> GDB complaints "During symbol reading: symtab found for 'macro.c',
> but that file is not covered in the compilation unit's macro information.
> No symbol "MAX_SIZE" in the current context" when printing the macro with
> the testcase file macro.c given below. This patch fixes this and prints
> the correct value.
>
> When gdb reads file number from DW_MACRO_start_file data in .debug_macro
> section, it will do name lookup in file_names and include_directories
> index table of .debug_line section. Prior to DWARFv5 include_directories[0]
> has no info, so a lookup at that index will return NULL and we have file name
> "macro.c". But in dwarfv5 current directory is explicitly represented at index 0
> (as shown in the snippet below), hence after lookup you get "PATH/macro.c".
> A snippet of .debug_line is as follows-
>
> include_directories[  0] = "/home/nitika/workspace"
> include_directories[  1] = "/usr/include"
> include_directories[  2] = "/usr/include/x86_64-linux-gnu/bits"
> include_directories[  3] = "/usr/include/x86_64-linux-gnu/sys"
> include_directories[  4] = "/usr/include/x86_64-linux-gnu/gnu"
> include_directories[  5] = "up_llvm/llvm-project/build/lib/clang/11.0.0/include"
> include_directories[  6] = "/usr/include/x86_64-linux-gnu/bits/types"
>
> file_names[  0]:
>            name: "macro.c"
>       dir_index: 0
>    md5_checksum: 0ee310711170f2dd9844b522e844207d
>
> Test case used (macro.c):
>
>  #define MAX_SIZE 10
> int main(void)
> {
>    int size = 0;
>    size = size + MAX_SIZE;
>
>    printf("\n The value of size is [%d]\n",size);
>
>    return 0;
> }
>
> clang -gdwarf-5 -fdebug-macro  macro.c -o macro.out
>
> Before the patch:
>
> gdb -q  macro.out -ex "start" -ex "set complaints 1"  -ex "p MAX_SIZE"
> Reading symbols from macro.out...
> Temporary breakpoint 1 at 0x4004df: file macro.c, line 7.
> Starting program: /home/nitika/workspace/macro.out
>
> Temporary breakpoint 1, main () at macro.c:7
> 7          int size = 0;
> During symbol reading: symtab found for 'macro.c',
> but that file is not covered in the compilation unit's macro information
> No symbol "MAX_SIZE" in current context.
>
> After the patch:
>
> gdb -q  macro.out -ex "start" -ex "p MAX_SIZE"
> Reading symbols from macro.out...
> Temporary breakpoint 1 at 0x4004df: file macro.c, line 7.
> Starting program: /home/nitika/workspace/macro.out
>
> Temporary breakpoint 1, main () at macro.c:7
> 7          int size = 0;
> $1 = 10
>
> Tested by running the testsuite before and after the patch with
>  -gdwarf-5 and there is no increase in the number of test cases
> that fails. Used clang 11.0.0.

But... is there an increase in number of test that pass?  Shouldn't some
macro-related test catch this somehow?  If not, it would be really good
to add a test for this.


>
> gdb/ChangeLog:
>
> 	* macrotab.c (macro_lookup_inclusion): In DWARF version 5 filename includes
> 	the full directory path.
> ---
>  gdb/macrotab.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/macrotab.c b/gdb/macrotab.c
> index 9ada436eaf..4ffb2d67cb 100644
> --- a/gdb/macrotab.c
> +++ b/gdb/macrotab.c
> @@ -507,7 +507,8 @@ struct macro_source_file *
>  macro_lookup_inclusion (struct macro_source_file *source, const char *name)
>  {
>    /* Is SOURCE itself named NAME?  */
> -  if (filename_cmp (name, source->filename) == 0)
> +  if (filename_cmp (name, source->filename) == 0 ||
> +      filename_cmp (basename (name), basename (source->filename)) == 0)
>      return source;

I'm not sure what the best solution is, since I don't really know this
code, but comparing just the basename sounds dangerous.  Let's say I
debug a file "foo.c" that includes a file "generated/foo.c", won't there
be confusion between the two files?

Simon


  reply	other threads:[~2020-10-04  2:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-10 15:06 [PATCH v2 1/2] DWARFv5: Handle DW_MACRO_define_strx and DW_MACRO_undef_strx macro entries nitachra
2020-08-10 15:06 ` [PATCH v2 2/2] DWARFv5: Fix for the filename complaint when printing macro nitachra
2020-10-04  2:32   ` Simon Marchi [this message]
2020-08-14 20:55 ` [PATCH v2 1/2] DWARFv5: Handle DW_MACRO_define_strx and DW_MACRO_undef_strx macro entries Tom Tromey

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=31a228c0-3be7-0819-727c-3df78c5c46ee@simark.ca \
    --to=simark@simark.ca \
    --cc=JiniSusan.George@amd.com \
    --cc=Nitika.Achra@amd.com \
    --cc=gdb-patches@sourceware.org \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).