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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 05 Jun 2012 03:14:46 +0200, Doug Evans wrote:
> 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);

I am fine with the patch.  FYI I would extend the comment a bit:

      /* 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.  That means it returns
	 this symtab even for addresses covered by compilation unit ranges but
	 not belonging to any symbol in this symtab.

	 STATIC_BLOCK is more inner than GLOBAL_BLOCK, this is the only reason
	 why choose it for LAST_SOURCE_START_ADDR..END_ADDR.  */


>        blockvector = make_blockvector (objfile);


Thanks,
Jan