This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix profiling on hppa (1/2)

On Thu, Feb 19, 2004 at 09:05:05PM -0800, Ulrich Drepper wrote:
> You have to describe in detail every single little change you do to
> generic code.  Why, what is the impact, ...

If the arch requires n-bit loads to be n-bit aligned, and
sizeof(unsigned short) != sizeof(unsigned long) then 'p->froms' can be
unaligned depending on TEXT_START and etext values, passed in from 
csu/gmon-start.c (__gmon_start__).

An explanation of the change required on line 117 of gmon/gmon.c:


114   p->lowpc = ROUNDDOWN(lowpc, HISTFRACTION * sizeof(HISTCOUNTER));
115   p->highpc = ROUNDUP(highpc, HISTFRACTION * sizeof(HISTCOUNTER));
116   p->textsize = p->highpc - p->lowpc;
117   p->kcountsize = ROUNDUP(p->textsize / HISTFRACTION, sizeof(*p->froms));
135   cp = calloc (p->kcountsize + p->fromssize + p->tossize, 1);
143   p->tos = (struct tostruct *)cp;
144   cp += p->tossize;
145   p->kcount = (HISTCOUNTER *)cp;
146   cp += p->kcountsize;
147   p->froms = (ARCINDEX *)cp;

When allocating 'cp' on 135, upon which we will store 'tos', 'kcount' 
and 'froms', we must be very careful about the start of each of these
elements, since their alignment is important. 

We begin by determining their individual types and sizes:

struct tostruct - 3 long sized value, alignment is 4-byte.
HISTCOUNTER - unsigned short, alignment is 2-byte.
ARCINDEX - unsigned long, alignment is 4-byte.

Some quick math shows that while 'p->highpc' and 'p->lowpc' are aligned
at 4-bytes, and their difference is a multiple of 4-bytes, when you 
divide by HISTFRACTION you are not guaranteed a value that is a multiple 
of 4-bytes.

The order of elements in the memory at 'cp' is as follows 

	|-- tos --|-- kcount --|-- froms --| 

It might happen that 'p->froms' is unaligned due to 'p->kcount'. To 
prevent this we round 'p->kcountsize' to 'sizeof(*p->froms)' on 117, 
adding 0 or 2 bytes of empty space at the end of 'p->kcount'.

Comments and corrections welcome.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]