public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: nitachra <Nitika.Achra@amd.com>
To: gdb-patches@sourceware.org
Cc: JiniSusan.George@amd.com, tamur@google.com, simark@simark.ca,
	nitachra <Nitika.Achra@amd.com>
Subject: [PATCH] DWARFv5: Handle location list for split dwarf.
Date: Tue, 17 Mar 2020 20:43:53 +0530	[thread overview]
Message-ID: <20200317151353.571-1-Nitika.Achra@amd.com> (raw)

This is the updated patch after rebasing.

Regards,
Nitika
---
GDB throws the error '<error reading variable: dwarf2_find_location_
expression: Corrupted DWARF expression.>' while printing the variable
value with executable file compiled with -gdwarf-5, -O1 and -gdwarf-split
flags. This patch fixes this error.

Tested by running the testsuite before and after the patch and there is
no increase in the number of test cases that fails. Tested with both
-gdwarf-4 and -gdwarf-5 flags. Also tested -gslit-dwarf along with -gdwarf-4
as well as -gdwarf-5 flags. Used clang version 10.0.0. This is the test case used-

int main()
{
    int arr[] = {1,2,3};
    for(int i = 0; i<3; i++)
        printf("%d",arr[i]);
    return 0;
}

clang -gdwarf-5 -O1 -gsplit-dwarf test.c -o test.out
gdb test.out
gdb> start
gdb> step
gdb> p i
dwarf2_find_location_expression: Corrupted DWARF expression.

gdb/ChangeLog:

   *dwarf2loc.c (enum debug_loc_kind): Added a new kind DEBUG_LOC_OFFSET_PAIR.
    (dwarf2_find_location_expression): Call the function decode_debug_loclists_
    addresses if DWARF version is 5 or more. Add applicable base address if the
    entry is DW_LLE_OFFSET_PAIR from DWO.
    (decode_debug_loclists_addresses): Return DEBUG_LOC_OFFSET_PAIR instead of
    DEBUG_LOC_START_END in case of DW_LLE_offset_pair.
---
 gdb/dwarf2/loc.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/gdb/dwarf2/loc.c b/gdb/dwarf2/loc.c
index 5155cff60d..cd8a6d33b0 100644
--- a/gdb/dwarf2/loc.c
+++ b/gdb/dwarf2/loc.c
@@ -92,6 +92,11 @@ enum debug_loc_kind
      as in .debug_loc.  */
   DEBUG_LOC_START_LENGTH = 3,
 
+   /* This is followed by two unsigned LEB128 operands. The values of these
+      operands are the starting and ending offsets, respectively, relative to
+      the applicable base address. */
+  DEBUG_LOC_OFFSET_PAIR = 4,
+
   /* An internal value indicating there is insufficient data.  */
   DEBUG_LOC_BUFFER_OVERFLOW = -1,
 
@@ -332,7 +337,7 @@ dwarf2_find_location_expression (struct dwarf2_loclist_baton *baton,
       enum debug_loc_kind kind;
       const gdb_byte *new_ptr = NULL; /* init for gcc -Wall */
 
-      if (baton->from_dwo)
+      if (baton->per_cu->version () < 5 && baton->from_dwo)
 	kind = decode_debug_loc_dwo_addresses (baton->per_cu,
 					       loc_ptr, buf_end, &new_ptr,
 					       &low, &high, byte_order);
@@ -358,6 +363,7 @@ dwarf2_find_location_expression (struct dwarf2_loclist_baton *baton,
 	  continue;
 	case DEBUG_LOC_START_END:
 	case DEBUG_LOC_START_LENGTH:
+	case DEBUG_LOC_OFFSET_PAIR:
 	  break;
 	case DEBUG_LOC_BUFFER_OVERFLOW:
 	case DEBUG_LOC_INVALID_ENTRY:
@@ -369,9 +375,11 @@ dwarf2_find_location_expression (struct dwarf2_loclist_baton *baton,
 
       /* Otherwise, a location expression entry.
 	 If the entry is from a DWO, don't add base address: the entry is from
-	 .debug_addr which already has the DWARF "base address".  We still add
-	 base_offset in case we're debugging a PIE executable.  */
-      if (baton->from_dwo)
+	 .debug_addr which already has the DWARF "base address". We still add
+	 base_offset in case we're debugging a PIE executable. However, if the
+	 entry is DW_LLE_offset_pair from a DWO, add the base address as the
+	 operands are offsets relative to the applicable base address. */
+      if (baton->from_dwo && kind != DEBUG_LOC_OFFSET_PAIR)
 	{
 	  low += base_offset;
 	  high += base_offset;
-- 
2.17.1


             reply	other threads:[~2020-03-17 15:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 15:13 nitachra [this message]
2020-03-18  2:45 ` Simon Marchi
  -- strict thread matches above, loose matches on Subject: below --
2020-03-22 12:56 nitachra
2020-03-18 14:15 nitachra
2020-03-20  3:20 ` Simon Marchi
2020-03-09  8:34 nitachra
2020-01-25 22:56 [PATCH]: " Achra, Nitika
2020-03-04  2:05 ` Simon Marchi

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=20200317151353.571-1-Nitika.Achra@amd.com \
    --to=nitika.achra@amd.com \
    --cc=JiniSusan.George@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    --cc=tamur@google.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).