This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: struct gmon_cg_arc_record


Jes Sorensen <jes@linuxcare.com> writes:

> struct raw_arc
>   {
>     /* FIXME: Checking a host compiler define means that we can't use
>        a cross gprof to the alpha.  */
> #ifdef __alpha__
>     char from_pc[8];
>     char self_pc[8];
>     char count[8];
> #else
>     char from_pc[4];
>     char self_pc[4];
>     char count[4];
> #endif
>   };

Doesn't this mean profiling on Alpha doesn't work at all?  THen of
course we should change it.

> struct gmon_hist_hdr
>   {
>     char low_pc[sizeof (char *)];       /* base pc address of sample buffer */
>     char high_pc[sizeof (char *)];      /* max pc address of sampled buffer */
>     char hist_size[4];                  /* size of sample buffer */
>     char prof_rate[4];                  /* profiling clock rate */
>     char dimen[15];                     /* phys. dim., usually "seconds" */
>     char dimen_abbrev;                  /* usually 's' for "seconds" */
>   };
> 
> For gprof it looks like this - note the extra version field:
> 
> struct raw_phdr
>   {
>     /* FIXME: Checking a host compiler define means that we can't use
>        a cross gprof to the alpha.  */
> #ifdef __alpha__
>     char low_pc[8];             /* base pc address of sample buffer */
>     char high_pc[8];            /* max pc address of sampled buffer */
> #else
>     char low_pc[4];             /* base pc address of sample buffer */
>     char high_pc[4];            /* max pc address of sampled buffer */
> #endif
>     char ncnt[4];               /* size of sample buffer (plus this header) */
> 
>     char version[4];            /* version number */
>     char profrate[4];           /* profiling clock rate */
>     char spare[3*4];            /* reserved */
>   };

No, you misread the definition.  The hist_size field corresponds to
ncnt.  The prof_rate rate to version.  The dimen and dimen_abbrev
field correspond to the profrate and spare field.

So we cannot simply add a new field, we would have to reorder them.
The question is: was it always like this?  Profiling certainly worked
for x86.

> Two questions, how will the latter affect architectures like the x86?

See above.  The history has to be investigated.

> Second what about Sparc64/MIPS64/PPC64? Do you guys have profile
> support running already that will break from this?

I wouldn't worry, only SPARC64 is at a stage where they can run
something and I guess they still don't mind breaking something
non-essential as this.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

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