http://sourceware.org/ml/gdb-patches/2012-06/msg00109.html

Subject: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling

Hi.

I was seeing the assert in dw2_find_pc_sect_psymtab trigger

and traced it to the fact that when pending_addrmap_interesting gets

set blockvector.map is used instead of blockvector.block.

The difference is that blockvector.block contains entries for the global

and static blocks whereas pending_addrmap doesn't.

This patch fixes this by making them consistent.

I suspect more work is necessary (e.g. can symtabs "overlap" even though

the individual pieces do not?).

But I first want to fix the regression introduced by the change

to dw2_find_pc_sect_psymtab: There is more code in a symtab than is

documented by function and lexical block pc ranges (e.g. C++ method thunks).

Regression tested on amd64-linux, and by verifying the assert no longer

triggers in the testcase I was using.

Ok to commit?

Note that this obviates the need for the patch in:

http://sourceware.org/ml/gdb-patches/2012-05/msg00958.html

Also note that this accompanies this patch:

http://sourceware.org/ml/gdb-patches/2012-06/msg00105.html

2012-06-04  Doug Evans  <dje@google.com>

	* buildsym.c (end_symtab): Add the range of the static block to

	the pending addrmap.

Index: buildsym.c

===================================================================

RCS file: /cvs/src/src/gdb/buildsym.c,v

retrieving revision 1.97

diff -u -p -r1.97 buildsym.c

--- ./gdb/buildsym.c	29 May 2012 20:23:17 -0000	1.97

+++ ./gdb/buildsym.c	5 Jun 2012 00:26:01 -0000

@@ -1024,8 +1027,15 @@ end_symtab (CORE_ADDR end_addr, struct o

     {

       /* Define the STATIC_BLOCK & GLOBAL_BLOCK, and build the

          blockvector.  */

-      finish_block (0, &file_symbols, 0, last_source_start_addr,

-		    end_addr, objfile);

+      struct block *static_block;

+

+      static_block = finish_block (0, &file_symbols, 0,

+				   last_source_start_addr, end_addr,

+				   objfile);

+      /* Mark the range of the static block so that if we end up using

+	 blockvector.map then find_block_in_blockvector behaves identically

+	 regardless of whether the addrmap is present.  */

+      record_block_range (static_block, last_source_start_addr, end_addr - 1);

       finish_block_internal (0, &global_symbols, 0, last_source_start_addr,

 			     end_addr, objfile, 1);

       blockvector = make_blockvector (objfile);