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

[Pedro Alves <palves@redhat.com>]

On 06/05/2012 02:14 AM, Doug Evans wrote:

> 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?).


Yeah, I suppose it could be conceivable, say with __attribute__ section
and/or linker scripts.

> 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?


FWIW, looks fine to me, but I don't really know all the ins and outs
of the symbol stuff.

> 
> 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
> --- buildsym.c	29 May 2012 20:23:17 -0000	1.97
> +++ 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);


-- 
Pedro Alves