compilation on SLES11/ppc64 can't find program counter (PC)

[GoogleCodeExporter]

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]

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]

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]

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]

I attached a profile of 'ls'.

Cheers,
John

Original comment by j.donn...@gmail.com on 9 Feb 2010 at 8:52

Attachments:

• ls.prof

[GoogleCodeExporter]

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]

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]

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