compilation on SLES11/ppc64 can't find program counter (PC)
GoogleCodeExporter opened this issue · 7 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
1. run configure on SLES11/ppc64 system
2.
3.
What is the expected output? What do you see instead?
I get "Could not find the PC. Will not try to compile libprofiler..."
Please use labels and text to provide additional information.
the PC (or NIP on ppc) is in a somewhat different location on this system:
uc_mcontext.gp_regs[PT_NIP]. I added this line to the configure script and
it works fine.
Original issue reported on code.google.com by j.donn...@gmail.com
on 3 Feb 2010 at 9:44
GoogleCodeExporter commented
OK, I added this line to the configure macro:
pc_fields="$pc_fields uc_mcontext.gp_regs[[PT_NIP]]" # SLES11 (ppc64)
Is that right? If so I'll put it in the next release.
Original comment by csilv...@gmail.com
on 4 Feb 2010 at 12:20
- Changed state: Started
- Added labels: Priority-Medium, Type-Porting
GoogleCodeExporter commented
that is right, except that it should be single brackets instead of double ones.
Furthermore, I get a profile, but pprof gives the error message "not a profile
file,
or old format profile file.".
Maybe pprof gets confused by the big-endianness and/or a 64-bit OS?
I could get you a login, if you need to do some tests.
With regards and many thanks for the quick reply,
John
Original comment by j.donn...@gmail.com
on 8 Feb 2010 at 8:21
GoogleCodeExporter commented
OK, great. (It needs to be double-brackets due to how m4 escaping works.)
} Furthermore, I get a profile, but pprof gives the error message "not a
profile file,
Can you attach the profile file to this bug report? That is hopefully enough to
figure out what's going on.
Original comment by csilv...@gmail.com
on 8 Feb 2010 at 11:19
GoogleCodeExporter commented
I attached a profile of 'ls'.
Cheers,
John
Original comment by j.donn...@gmail.com
on 9 Feb 2010 at 8:52
Attachments:
GoogleCodeExporter commented
Hmm, looks likely to be an endianness issue. pprof has this comment:
---
# Normal 64-bit header: All entries are doubled in size. The first
# word (little-endian) should contain the real value, the second should
# be zero.
} elsif ($slots->get(1) != 0 ||
$slots->get(2) < 3 ||
$slots->get(3) != 0 ||
$slots->get(5) != 0 ||
$slots->get(7) != 0) {
error("$fname: not a profile file, or old format profile file\n");
---
But the profile looks like it's been written in big-endian order. In
particular, for
your profile, get(2) is 0, and get(3) is 3, rather than the other way around.
I'm not sure what the best solution is: to have pprof read both big-endian and
little-endian, or to make sure perftools always writes profiles in little-endian
order. In either case, I'll look to fix this for the next release. Do you mind
opening a separate bug report so I can track this issue separately?
Original comment by csilv...@gmail.com
on 9 Feb 2010 at 10:58
GoogleCodeExporter commented
profile issue with endianness copied to issue #216. The original issue of the
program
counter is fixed, so this can be closed.
Original comment by j.donn...@gmail.com
on 10 Feb 2010 at 10:20
GoogleCodeExporter commented
This should be fixed in perftools 1.6, just released.
Original comment by csilv...@gmail.com
on 5 Aug 2010 at 8:47
- Changed state: Fixed