Re: [patch][rfa] gprof: VMA range computation

Re: [patch][rfa] gprof: VMA range computation

[Nick Clifton]

Hi Dave,

> 2002-07-23  Dave Brolley  <brolley@redhat.com>
> 
> 	* corefile.c (core_create_function_syms): Use the end of the section
> 	containing the symbol to compute max_vma.

Approved - please apply.

Cheers
        Nick

Re: [patch][rfa] gprof: VMA range computation

[Dave Brolley]

Nick Clifton wrote:

> Hi Dave,
>
> > 2002-07-23  Dave Brolley  <brolley@redhat.com>
> >
> >       * corefile.c (core_create_function_syms): Use the end of the section
> >       containing the symbol to compute max_vma.
>
> Approved - please apply.
>
> Cheers
>         Nick

Done. Thanks!

[patch][rfa] gprof: VMA range computation

[Dave Brolley]

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

Hi,

The attached patch addresses a problem in grof in which references to
the function which has the highest VMA are erroneously attributed to
the sentinal function <hicore>.

The function core_create_function_syms creates a table of function
symbols and their addresses. This is used to determine which address
ranges belong to which function. In order to classify addresses which
are before the first function and after the last one, two "sentinal"
entriies are created - one with address zero (<locore>)and one with an
address intended to be beyond the end of the function with the highest
VMA (<hicore>). The problem is that only the starting address of each
function is available and so, <hicore> is assigned an address wehich
is one byte higher than the start of the last function. This is
incorrect, since legitemate addresses in this last function are then
attributed to <hicore>.

This patch examines the section containing each function, if
available, and computes the VMA address of the end of the section. The
highest of these addresses is then used as the start of <hicore>. In
this way addresses within the function with the highest VMA are
correctly classified.

Tested against the internal port which exposed the problem.

Seeking approval to commit.

Dave

[-- Attachment #2: vma.ChangeLog --]
[-- Type: text/plain, Size: 162 bytes --]

2002-07-23  Dave Brolley  <brolley@redhat.com>

	* corefile.c (core_create_function_syms): Use the end of the section
	containing the symbol to compute max_vma.


[-- Attachment #3: vma.patch.txt --]
[-- Type: text/plain, Size: 1275 bytes --]

Index: gprof/corefile.c
===================================================================
RCS file: /cvs/src/src/gprof/corefile.c,v
retrieving revision 1.11
diff -c -p -r1.11 corefile.c
*** gprof/corefile.c	1 Feb 2002 08:24:15 -0000	1.11
--- gprof/corefile.c	23 Jul 2002 17:32:06 -0000
*************** core_create_function_syms (cbfd)
*** 542,549 ****
        if (class == 't')
  	symtab.limit->is_static = true;
  
        min_vma = MIN (symtab.limit->addr, min_vma);
!       max_vma = MAX (symtab.limit->addr, max_vma);
  
        /* If we see "main" without an initial '_', we assume names
  	 are *not* prefixed by '_'.  */
--- 542,556 ----
        if (class == 't')
  	symtab.limit->is_static = true;
  
+       /* Keep track of the minimum and maximum vma addresses used by all
+ 	 symbols.  When computing the max_vma, use the ending address of the
+ 	 section containing the symbol, if available.  */
        min_vma = MIN (symtab.limit->addr, min_vma);
!       if (core_syms[i]->section)
! 	max_vma = MAX (core_syms[i]->section->vma
! 		       + core_syms[i]->section->_cooked_size - 1, max_vma);
!       else
! 	max_vma = MAX (symtab.limit->addr, max_vma);
  
        /* If we see "main" without an initial '_', we assume names
  	 are *not* prefixed by '_'.  */