Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jie Zhang <jie.zhang@analog.com>
To: gdb-patches@sourceware.org
Subject: [PATCH] Fix a bug of addrmap
Date: Tue, 21 Oct 2008 04:44:00 -0000	[thread overview]
Message-ID: <48FD5DE1.9090105@analog.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Hi,

I encountered a problem when trying CVS HEAD gdb with gcc-4.1, which has
no .debug_ranges support. Below is the test case:

$ cat main.c
int main ()
{
    return 0;
}

extern void __attribute__ ((__section__ (".init.text"))) foo_init (void);
void foo_init ()
{
    return;
}

$ cat foo.c
int foo ()
{
    return 0;
}

$ gcc-4.1 -o test main.c foo.c -g

CVS HEAD gdb cannot show the source line of foo.
$ gdb test
GNU gdb (GDB) 6.8.50.20081020-cvs
[snip]
(gdb) b foo
Breakpoint 1 at 0x400458

while gdb-6.8 can
$ gdb test
GNU gdb 6.8
[snip]
(gdb) b foo
Breakpoint 1 at 0x400458: file foo.c, line 3.

Since gcc-4.1 does not generate .debug_ranges, gdb tries to create
addrmap from low_pc and high_pc. When creating mutable addrmap, the
address range of main.c is treated as contiguous, e.g. [0x400448,
0x40053e], while foo.c is e.g. [0x400454, 0x40045f], which is embedded
in the former. In current gdb, the value of the start and end
transitions for foo.c are initialized as same as the value of the start
one for main.c. Then later in addrmap_mutable_set_empty, those
transitions are removed.

This patch should fix this case. Is it OK?


Regards,
Jie


[-- Attachment #2: gdb-addrmap-embedded-range.diff --]
[-- Type: text/x-patch, Size: 2480 bytes --]


	* addrmap.c (force_transition): Add new argument start.
	(addrmap_mutable_set_empty): Establish the end transition
	before the start transition.

Index: addrmap.c
===================================================================
RCS file: /cvs/src/src/gdb/addrmap.c,v
retrieving revision 1.4
diff -u -p -r1.4 addrmap.c
--- addrmap.c	1 Jan 2008 22:53:09 -0000	1.4
+++ addrmap.c	21 Oct 2008 03:42:19 -0000
@@ -291,18 +291,27 @@ addrmap_splay_tree_insert (struct addrma
 
 /* Without changing the mapping of any address, ensure that there is a
    tree node at ADDR, even if it would represent a "transition" from
-   one value to the same value.  */
+   one value to the same value.  If START is non-zero, this is the
+   start transition of the address range.  Otherwise, it's the end
+   transition.  */
 static void
-force_transition (struct addrmap_mutable *this, CORE_ADDR addr)
+force_transition (struct addrmap_mutable *this, CORE_ADDR addr, int start)
 {
   splay_tree_node n
     = addrmap_splay_tree_lookup (this, addr);
 
   if (! n)
     {
-      n = addrmap_splay_tree_predecessor (this, addr);
-      addrmap_splay_tree_insert (this, addr,
-                                 n ? addrmap_node_value (n) : NULL);
+      void *value;
+
+      if (start)
+	value = NULL;
+      else
+	{
+	  n = addrmap_splay_tree_predecessor (this, addr);
+	  value = n ? addrmap_node_value (n) : NULL;
+	}
+      addrmap_splay_tree_insert (this, addr, value);
     }
 }
 
@@ -328,10 +337,16 @@ addrmap_mutable_set_empty (struct addrma
      - First pass: change all NULL regions to OBJ.
      - Second pass: remove any unnecessary transitions.  */
 
-  /* Establish transitions at the start and end.  */
-  force_transition (map, start);
+  /* Establish transitions at the start and end.  The end transition
+     is established first such that its value will be initialized as
+     same as the value of its predecessor.  The value of the start
+     transition will always be initialized to NULL.  With this
+     establishing order, the value of these transitions will be set
+     properly later even if the given address range is embedded in
+     another address range.  */
   if (end_inclusive < CORE_ADDR_MAX)
-    force_transition (map, end_inclusive + 1);
+    force_transition (map, end_inclusive + 1, 0);
+  force_transition (map, start, 1);
 
   /* Walk the area, changing all NULL regions to OBJ.  */
   for (n = addrmap_splay_tree_lookup (map, start), gdb_assert (n);


             reply	other threads:[~2008-10-21  4:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-21  4:44 Jie Zhang [this message]
2008-11-03  6:09 ` PING: " Jie Zhang
2008-11-25 23:09   ` Tom Tromey
2008-11-26  6:34     ` Joel Brobecker
2008-11-26 13:53       ` Tom Tromey
2008-11-26 14:24       ` Daniel Jacobowitz
2008-11-26 15:05         ` Daniel Jacobowitz
2008-11-27 14:45       ` Tom Tromey
2008-12-08 23:12         ` Joel Brobecker

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=48FD5DE1.9090105@analog.com \
    --to=jie.zhang@analog.com \
    --cc=gdb-patches@sourceware.org \
    /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