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] |
64 bit port maintainers please read! >>>>> "Ulrich" == Ulrich Drepper <drepper@redhat.com> writes: Ulrich> Hum, for new 64-bit architecture I'd suggest changing the Ulrich> on-disk format. There is no reason to make things slower than Ulrich> necessary. Ok Ulrich> For Alpha, I'd also go with a new format if rth thinks this is Ulrich> OK. Ulrich> The [4] in the data structure definition clearly is motivated Ulrich> by the use in 32-bit architecture. Hmmm something is certainly fishy here, comparing glibc-2.2 with the difinitions found in gprof it looks like we should update glibc to match gprof. Ie. the arc structure in gprof looks like this: 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 }; We also have a mismatch in gmon_list_hdr: in glibc it looks like this: 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 */ }; My suggestion would be that we change count in gmon_cg_arc_record to sizeof(char *) like it is in gprof and introduce the version field as well. Two questions, how will the latter affect architectures like the x86? Second what about Sparc64/MIPS64/PPC64? Do you guys have profile support running already that will break from this? Jes
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |