You can subscribe to this list here.
2001 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
(50) |
Oct
(74) |
Nov
(28) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(27) |
Mar
(88) |
Apr
(21) |
May
(59) |
Jun
(41) |
Jul
(61) |
Aug
(89) |
Sep
(179) |
Oct
(152) |
Nov
(190) |
Dec
(92) |
2003 |
Jan
(140) |
Feb
(160) |
Mar
(193) |
Apr
(107) |
May
(84) |
Jun
(60) |
Jul
(97) |
Aug
(97) |
Sep
(42) |
Oct
(105) |
Nov
(99) |
Dec
(52) |
2004 |
Jan
(99) |
Feb
(97) |
Mar
(62) |
Apr
(73) |
May
(94) |
Jun
(37) |
Jul
(32) |
Aug
(89) |
Sep
(87) |
Oct
(72) |
Nov
(114) |
Dec
(35) |
2005 |
Jan
(25) |
Feb
(42) |
Mar
(120) |
Apr
(151) |
May
(71) |
Jun
(36) |
Jul
(35) |
Aug
(92) |
Sep
(19) |
Oct
(57) |
Nov
(77) |
Dec
(61) |
2006 |
Jan
(107) |
Feb
(114) |
Mar
(66) |
Apr
(101) |
May
(74) |
Jun
(64) |
Jul
(42) |
Aug
(51) |
Sep
(106) |
Oct
(118) |
Nov
(138) |
Dec
(162) |
2007 |
Jan
(148) |
Feb
(222) |
Mar
(73) |
Apr
(160) |
May
(166) |
Jun
(125) |
Jul
(184) |
Aug
(58) |
Sep
(41) |
Oct
(102) |
Nov
(111) |
Dec
(52) |
2008 |
Jan
(104) |
Feb
(67) |
Mar
(48) |
Apr
(125) |
May
(114) |
Jun
(98) |
Jul
(206) |
Aug
(89) |
Sep
(88) |
Oct
(163) |
Nov
(115) |
Dec
(113) |
2009 |
Jan
(131) |
Feb
(85) |
Mar
(157) |
Apr
(198) |
May
(202) |
Jun
(154) |
Jul
(156) |
Aug
(75) |
Sep
(80) |
Oct
(148) |
Nov
(88) |
Dec
(83) |
2010 |
Jan
(78) |
Feb
(59) |
Mar
(89) |
Apr
(54) |
May
(92) |
Jun
(66) |
Jul
(38) |
Aug
(73) |
Sep
(84) |
Oct
(91) |
Nov
(52) |
Dec
(62) |
2011 |
Jan
(86) |
Feb
(68) |
Mar
(129) |
Apr
(121) |
May
(154) |
Jun
(81) |
Jul
(55) |
Aug
(55) |
Sep
(58) |
Oct
(115) |
Nov
(88) |
Dec
(95) |
2012 |
Jan
(105) |
Feb
(62) |
Mar
(52) |
Apr
(54) |
May
(103) |
Jun
(89) |
Jul
(152) |
Aug
(73) |
Sep
(58) |
Oct
(60) |
Nov
(52) |
Dec
(90) |
2013 |
Jan
(102) |
Feb
(63) |
Mar
(68) |
Apr
(128) |
May
(82) |
Jun
(94) |
Jul
(87) |
Aug
(29) |
Sep
(24) |
Oct
(25) |
Nov
(40) |
Dec
(51) |
2014 |
Jan
(41) |
Feb
(60) |
Mar
(33) |
Apr
(22) |
May
(38) |
Jun
(23) |
Jul
(86) |
Aug
(113) |
Sep
(23) |
Oct
(22) |
Nov
(18) |
Dec
(13) |
2015 |
Jan
(40) |
Feb
(12) |
Mar
(28) |
Apr
(32) |
May
(53) |
Jun
(65) |
Jul
(27) |
Aug
(6) |
Sep
(13) |
Oct
(25) |
Nov
(48) |
Dec
(19) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
(23) |
Apr
(31) |
May
(19) |
Jun
(28) |
Jul
(19) |
Aug
(2) |
Sep
(9) |
Oct
(18) |
Nov
(10) |
Dec
(4) |
2017 |
Jan
(23) |
Feb
(42) |
Mar
(13) |
Apr
(5) |
May
(7) |
Jun
(26) |
Jul
(13) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(27) |
Dec
(4) |
2018 |
Jan
(9) |
Feb
(22) |
Mar
(27) |
Apr
(16) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(1) |
Sep
(36) |
Oct
(17) |
Nov
(1) |
Dec
(5) |
2019 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(4) |
Nov
(5) |
Dec
(13) |
2020 |
Jan
(60) |
Feb
(57) |
Mar
(4) |
Apr
(71) |
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(2) |
Dec
|
2021 |
Jan
(42) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: William C. <wc...@nc...> - 2003-01-30 14:52:30
|
Philippe Elie wrote: > William Cohen wrote: > > >> John Levon wrote: >> >>>> - Fix opcontrol to handle 64bit kernel offsets. Im not sure >>>> why opcontrol was using perl where op_start just parsed it with >>>> grep/cut. >>> >>> >>> >>> >>> Looking at the objdump header's values should be more portable. Will >>> made this change : >>> >>> >>>> - tmp1=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", >>>> (hex($d))' $range_info` >>>> - tmp2=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", >>>> (hex($c) + hex($d))' $range_info` >>> >>> >>> >>> >>> I'd prefer to just fix this code. Will ? >> >> >> >> The old implementation assumed that all kernels mark the end of the >> text with _stext. There were some kernels that I looked at the didn't >> mark the end in that manner. I don't remember which ones specifically >> (I looked at sparc, ia64, or ppc32). Rather than trying to enumerate >> all the possible special symbol name variation on the different >> targets and try to predict future name variations, I just decided to >> extract the start of text and the length using objdump and then >> compute the end. >> >> How did this code fail on the ppc64? > > > we can't do arithmetic in perl nor using print %[integer format] > as we manipulate unsigned long long and perl can't handle them. > String must be manipulate as it and passed to daemon. This means > interface to daemon must be changed, passing start and size rather > start and end. Using nm is not going to work with stripped kernel. Red Hat distributes some kernel as stripped, so going back to nm is not going to work either. Could we use the --adjust-vma option in objdump to compute the end address? first objdump used to get start address and length, make a second call to objdump with '--adjust-vma=length' and extract the end address from that. Having the deamon accept the start and length as an option sounds like less of a hack. -Will > > Anton is objdump -h parsing will give the same results as nm ? > > regards, > Phil > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Philippe E. <ph...@wa...> - 2003-01-30 14:43:00
|
John Levon wrote: > On Thu, Jan 30, 2003 at 02:14:32PM +1100, Anton Blanchard wrote: > > >>- Add lookup_dcookie syscall number for ppc32/ppc64 > > > OK > > >>- Fix lookup_dcookie on ppc32. The ABI passes long longs as an odd even > > > Looks like you can use Randolph's version here. No, it's broken, I'm commiting the opd_cookie.h part as it. Later if we get a working parisc identical to this one we will merge lookup_dcookie() definition. >>- Pad 32bit addresses to 64bit when printing. We arent going to want this >> on x86 but it makes the output on ppc64 nicer. > > > This can wait until a solution that works for all is done. The following is ok, it pessimes output on 32/64 when profiling a 32 bits application but will be sufficient for now // FIXME: do we need a better way to shrink output ? out << hex << setw(sizeof(bfd_vma) == 8 ? 16 : 8)) << setfill('0') << f.sample.vma; it remains to fix the kernel range parsing. regards, Phil |
From: Philippe E. <ph...@wa...> - 2003-01-30 14:33:10
|
Randolph Chung wrote: > Index: opd_cookie.h > +#if defined(__hppa__) > +static inline int lookup_dcookie(cookie_t cookie, char * buf, size_t size) > +{ > + /* ABI specifies that 64-bit values cannot be passed on odd-numbered > + * registers > + */ > + extern size_t kernel_pointer_size; > + > + if (kernel_pointer_size == 8) { > + return syscall(opd_nr_lookup_dcookie, > + (unsigned long)(cookie >> 32), > + (unsigned long)(cookie & 0xffffffff), buf, size); > + } else { > + return syscall(opd_nr_lookup_dcookie, (unsigned long)cookie, > + buf, size); John, we discuss Randolph and me about this else part, it can't work and it seems there is no easy work-around. I'm committing something like: } else { printf("parsic 32 bits kernel unsupported\n"); exit(EXIT_FAILURE); Randolph, is the solution to add a wrapper in sys_parisc.c, in the same way as parisc_pread64() ? regards, Phil |
From: Philippe E. <ph...@wa...> - 2003-01-30 14:26:30
|
William Cohen wrote: > John Levon wrote: > >>> - Fix opcontrol to handle 64bit kernel offsets. Im not sure >>> why opcontrol was using perl where op_start just parsed it with >>> grep/cut. >> >> >> >> Looking at the objdump header's values should be more portable. Will >> made this change : >> >> >>> - tmp1=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", >>> (hex($d))' $range_info` >>> - tmp2=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", >>> (hex($c) + hex($d))' $range_info` >> >> >> >> I'd prefer to just fix this code. Will ? > > > The old implementation assumed that all kernels mark the end of the text > with _stext. There were some kernels that I looked at the didn't mark > the end in that manner. I don't remember which ones specifically (I > looked at sparc, ia64, or ppc32). Rather than trying to enumerate all > the possible special symbol name variation on the different targets and > try to predict future name variations, I just decided to extract the > start of text and the length using objdump and then compute the end. > > How did this code fail on the ppc64? we can't do arithmetic in perl nor using print %[integer format] as we manipulate unsigned long long and perl can't handle them. String must be manipulate as it and passed to daemon. This means interface to daemon must be changed, passing start and size rather start and end. Anton is objdump -h parsing will give the same results as nm ? regards, Phil |
From: William C. <wc...@nc...> - 2003-01-30 03:48:19
|
John Levon wrote: > On Thu, Jan 30, 2003 at 02:14:32PM +1100, Anton Blanchard wrote: > > >>- Add lookup_dcookie syscall number for ppc32/ppc64 > > > OK > > >>- Fix lookup_dcookie on ppc32. The ABI passes long longs as an odd even > > > Looks like you can use Randolph's version here. > > >>- Pad 32bit addresses to 64bit when printing. We arent going to want this >> on x86 but it makes the output on ppc64 nicer. > > > This can wait until a solution that works for all is done. > > >>- Fix opcontrol to handle 64bit kernel offsets. Im not sure >> why opcontrol was using perl where op_start just parsed it with >> grep/cut. > > > Looking at the objdump header's values should be more portable. Will > made this change : > > >>- tmp1=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", (hex($d))' $range_info` >>- tmp2=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", (hex($c) + hex($d))' $range_info` > > > I'd prefer to just fix this code. Will ? The old implementation assumed that all kernels mark the end of the text with _stext. There were some kernels that I looked at the didn't mark the end in that manner. I don't remember which ones specifically (I looked at sparc, ia64, or ppc32). Rather than trying to enumerate all the possible special symbol name variation on the different targets and try to predict future name variations, I just decided to extract the start of text and the length using objdump and then compute the end. How did this code fail on the ppc64? I will take a look at this Thursday morning. -Will > > regards > john > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: John L. <le...@mo...> - 2003-01-30 03:27:21
|
On Thu, Jan 30, 2003 at 02:14:32PM +1100, Anton Blanchard wrote: > - Add lookup_dcookie syscall number for ppc32/ppc64 OK > - Fix lookup_dcookie on ppc32. The ABI passes long longs as an odd even Looks like you can use Randolph's version here. > - Pad 32bit addresses to 64bit when printing. We arent going to want this > on x86 but it makes the output on ppc64 nicer. This can wait until a solution that works for all is done. > - Fix opcontrol to handle 64bit kernel offsets. Im not sure > why opcontrol was using perl where op_start just parsed it with > grep/cut. Looking at the objdump header's values should be more portable. Will made this change : > - tmp1=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", (hex($d))' $range_info` > - tmp2=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", (hex($c) + hex($d))' $range_info` I'd prefer to just fix this code. Will ? regards john |
From: Anton B. <an...@sa...> - 2003-01-30 03:18:17
|
> John planned to release by tomorrow. If you want this change > in oprofile 0.5 send your patch quickly please else the 0.5 > tarball will be broken for ppc. Previous message in this thread > show how we handled it for parisc. Here is my current patch: - Add lookup_dcookie syscall number for ppc32/ppc64 - Fix lookup_dcookie on ppc32. The ABI passes long longs as an odd even register pair. When we call syscall() the long long cookie ends up in registers r5 and r6 (with r4 being empty). The syscall() function simply shifts r4-r8 down by one, leaving cookie in r4 and r5. To fix this we pass it in as two longs. - Pad 32bit addresses to 64bit when printing. We arent going to want this on x86 but it makes the output on ppc64 nicer. - Your patch for op_to_source - Fix op_start and opcontrol to handle ppc64 kernels. The start address in System.map is different - Fix opcontrol to handle 64bit kernel offsets. Im not sure why opcontrol was using perl where op_start just parsed it with grep/cut. Anton diff -ru oprofile/daemon/opd_cookie.h oprofile_work2/daemon/opd_cookie.h --- oprofile/daemon/opd_cookie.h 2003-01-19 03:12:35.000000000 +1100 +++ oprofile_work2/daemon/opd_cookie.h 2003-01-28 10:41:32.000000000 +1100 @@ -19,13 +19,23 @@ #define opd_nr_lookup_dcookie 253 #elif defined(__alpha__) #define opd_nr_lookup_dcookie 406 +#elif defined(__powerpc__) +#define opd_nr_lookup_dcookie 235 #else #error Please define lookup_dcookie for your architecture #endif +#if defined(__powerpc__) && !defined(__powerpc64__) +static int lookup_dcookie(u_int64_t cookie, char * buf, size_t size) +{ + return syscall(opd_nr_lookup_dcookie, (unsigned long)(cookie >> 32), + (unsigned long)(cookie & 0xffffffff), buf, size); +} +#else static inline int lookup_dcookie(cookie_t cookie, char * buf, size_t size) { return syscall(opd_nr_lookup_dcookie, cookie, buf, size); } +#endif #endif /* OPD_COOKIE_H */ diff -ru oprofile/pp/format_output.cpp oprofile_work2/pp/format_output.cpp --- oprofile/pp/format_output.cpp 2002-12-15 03:39:29.000000000 +1100 +++ oprofile_work2/pp/format_output.cpp 2003-01-28 10:42:02.000000000 +1100 @@ -332,7 +332,7 @@ { ostringstream out; - out << hex << setw(8) << setfill('0') << f.sample.vma; + out << hex << setw(16) << setfill('0') << f.sample.vma; return out.str(); } diff -ru oprofile/pp/op_to_source.cpp oprofile_work2/pp/op_to_source.cpp --- oprofile/pp/op_to_source.cpp 2002-12-15 03:39:29.000000000 +1100 +++ oprofile_work2/pp/op_to_source.cpp 2003-01-28 23:52:01.000000000 +1100 @@ -819,8 +819,9 @@ // do not use the bfd equivalent: // - it does not skip space at begin // - we does not need cross architecture compile so the native - // strtoul must work (assuming unsigned long can contain a vma) - bfd_vma vma = strtoul(str_vma.c_str(), NULL, 16); + // strtoull must work, assuming unsigned long long can contain a vma + // and on 32/64 bits box bfd_vma is 64 bits + bfd_vma vma = strtoull(str_vma.c_str(), NULL, 16); return samples->find_symbol(vma); } @@ -844,8 +845,9 @@ // do not use the bfd equivalent: // - it does not skip space at begin // - we does not need cross architecture compile so the native - // strtoul must work (assuming unsigned long can contain a vma) - bfd_vma vma = strtoul(str.c_str(), NULL, 16); + // strtoull must work, assuming unsigned long long can contain a vma + // and on 32/64 bits box bfd_vma is 64 bits + bfd_vma vma = strtoull(str.c_str(), NULL, 16); sample_entry const * sample = samples->find_sample(vma); if (sample) { diff -ru oprofile/utils/op_start_25 oprofile_work2/utils/op_start_25 --- oprofile/utils/op_start_25 2002-12-03 14:53:44.000000000 +1100 +++ oprofile_work2/utils/op_start_25 2003-01-30 14:00:14.000000000 +1100 @@ -141,6 +141,10 @@ return; fi tmp1=`nm $VMLINUX | grep ' A _text'` + # match start of kernel on ppc64 + if test -z "$tmp1"; then + tmp1=`nm $VMLINUX | grep ' T _stext'` + fi tmp2=`nm $VMLINUX | grep ' A _end'` if test -z "$tmp1" -o -z "$tmp2"; then echo "Couldn't determine kernel start/end" >&2 diff -ru oprofile/utils/opcontrol oprofile_work2/utils/opcontrol --- oprofile/utils/opcontrol 2003-01-15 23:19:21.000000000 +1100 +++ oprofile_work2/utils/opcontrol 2003-01-30 14:01:36.000000000 +1100 @@ -326,9 +326,15 @@ if test ! -z "$KERNEL_RANGE"; then return; fi - range_info=`objdump -h $VMLINUX | grep ".text "` - tmp1=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", (hex($d))' $range_info` - tmp2=`perl -le '($a, $b, $c, $d) = @ARGV; printf "%x\n", (hex($c) + hex($d))' $range_info` + + tmp1=`nm $VMLINUX | grep ' A _text'` + # match start of kernel on ppc64 + if test -z "$tmp1"; then + tmp1=`nm $VMLINUX | grep ' T _stext'` + fi + tmp2=`nm $VMLINUX | grep ' A _end'` + tmp1=`echo $tmp1 | cut -d" " -f 1` + tmp2=`echo $tmp2 | cut -d" " -f 1` if test -z "$tmp1" -o -z "$tmp2"; then echo "Couldn't determine kernel start/end" >&2 |
From: Philippe E. <ph...@wa...> - 2003-01-29 19:52:19
|
Anton Blanchard wrote: >>try the attached patch. It's probably not sufficient but it's >>required. If it don't work I need more feedback where vma are >>truncated, send me typical -V output for a truncated address > > > Nice work, it fixes the problem. Apart from a few trivial bits I'll > forward on (eg passing a long long in a syscall is arch/ABI dependent) > oprofile is working perfectly with ppc32 userspace and ppc64 kernel. John planned to release by tomorrow. If you want this change in oprofile 0.5 send your patch quickly please else the 0.5 tarball will be broken for ppc. Previous message in this thread show how we handled it for parisc. regards, Phil |
From: Randolph C. <ran...@ta...> - 2003-01-29 16:27:35
|
> + if (kernel_pointer_size == 64) { oops! as John pointed out to me, this should be 8 ... here's an updated patch randolph Index: opd_cookie.h =================================================================== RCS file: /cvsroot/oprofile/oprofile/daemon/opd_cookie.h,v retrieving revision 1.2 diff -u -p -r1.2 opd_cookie.h --- opd_cookie.h 18 Jan 2003 16:12:35 -0000 1.2 +++ opd_cookie.h 29 Jan 2003 16:01:52 -0000 @@ -15,17 +15,38 @@ #include <unistd.h> #include "op_types.h" -#ifdef __i386__ +#if defined(__i386__) #define opd_nr_lookup_dcookie 253 +#elif defined(__hppa__) +#define opd_nr_lookup_dcookie 223 #elif defined(__alpha__) #define opd_nr_lookup_dcookie 406 #else #error Please define lookup_dcookie for your architecture #endif +#if defined(__hppa__) +static inline int lookup_dcookie(cookie_t cookie, char * buf, size_t size) +{ + /* ABI specifies that 64-bit values cannot be passed on odd-numbered + * registers + */ + extern size_t kernel_pointer_size; + + if (kernel_pointer_size == 8) { + return syscall(opd_nr_lookup_dcookie, + (unsigned long)(cookie >> 32), + (unsigned long)(cookie & 0xffffffff), buf, size); + } else { + return syscall(opd_nr_lookup_dcookie, (unsigned long)cookie, + buf, size); + } +} +#else static inline int lookup_dcookie(cookie_t cookie, char * buf, size_t size) { return syscall(opd_nr_lookup_dcookie, cookie, buf, size); } +#endif #endif /* OPD_COOKIE_H */ |
From: Randolph C. <ran...@ta...> - 2003-01-29 16:04:42
|
> Nice work, it fixes the problem. Apart from a few trivial bits I'll > forward on (eg passing a long long in a syscall is arch/ABI dependent) > oprofile is working perfectly with ppc32 userspace and ppc64 kernel. parisc64 also needs this... so here's a patch :) Index: opd_cookie.h =================================================================== RCS file: /cvsroot/oprofile/oprofile/daemon/opd_cookie.h,v retrieving revision 1.2 diff -u -p -r1.2 daemon/opd_cookie.h --- daemon/opd_cookie.h 18 Jan 2003 16:12:35 -0000 1.2 +++ daemon/opd_cookie.h 29 Jan 2003 16:01:52 -0000 @@ -15,17 +15,38 @@ #include <unistd.h> #include "op_types.h" -#ifdef __i386__ +#if defined(__i386__) #define opd_nr_lookup_dcookie 253 +#elif defined(__hppa__) +#define opd_nr_lookup_dcookie 223 #elif defined(__alpha__) #define opd_nr_lookup_dcookie 406 #else #error Please define lookup_dcookie for your architecture #endif +#if defined(__hppa__) +static inline int lookup_dcookie(cookie_t cookie, char * buf, size_t size) +{ + /* ABI specifies that 64-bit values cannot be passed on odd-numbered + * registers + */ + extern size_t kernel_pointer_size; + + if (kernel_pointer_size == 64) { + return syscall(opd_nr_lookup_dcookie, + (unsigned long)(cookie >> 32), + (unsigned long)(cookie & 0xffffffff), buf, size); + } else { + return syscall(opd_nr_lookup_dcookie, (unsigned long)cookie, + buf, size); + } +} +#else static inline int lookup_dcookie(cookie_t cookie, char * buf, size_t size) { return syscall(opd_nr_lookup_dcookie, cookie, buf, size); } +#endif #endif /* OPD_COOKIE_H */ -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ |
From: Anton B. <an...@sa...> - 2003-01-29 15:02:16
|
> try the attached patch. It's probably not sufficient but it's > required. If it don't work I need more feedback where vma are > truncated, send me typical -V output for a truncated address Nice work, it fixes the problem. Apart from a few trivial bits I'll forward on (eg passing a long long in a syscall is arch/ABI dependent) oprofile is working perfectly with ppc32 userspace and ppc64 kernel. Anton |
From: William C. <wc...@nc...> - 2003-01-28 16:59:18
|
I have been working on getting the ia64 oprofile code to use the newer Linux 2.5 interface. I have a patch for the 2.4.20 kernel. This is on top of the ia64 patch for 2.4.20 kernel from linuxia64.org and the Red Hat 2.4.20 oprofile backport patch. The 2.4.20 kernel build won't get very far without the kernel patch from linuxia64.org. The patches to the kernel were installed in the following order to the 2.4.20 kernel: patch -p1 < ../linux-2.4.20-ia64-021210.diff patch -p1 < ../linux-2.4.20-oprofile-public-1.patch patch -p1 < ../linux-2.4.20-ia64-oprofile-20030128.patch The attached patch adds the basic timer_int functionality for the ia64. It does not use the performance monitoring hardware on the ia64. The patch is still being developed, but I thought I people might be interested in the patch and provide some feedback on the patch. -Will |
From: Philippe E. <ph...@wa...> - 2003-01-28 12:18:57
|
Anton Blanchard wrote: > Running a ppc32 oprofile executable on a ppc64 kernel. (ie 32bit > executable, 64bit kernel). When I run with -V op_to_source shows all the > function offsets have the top 32 bits truncated. > > >>Falk Hueffner report it works on alpha (at least results seems sensible) > > > I had a word with Alan Modra and there could be interesting things going > on with bfd. Apparently on 32bit hosts, bfd_vma can be either a long or > long long depending on how its compiled (eg compiling ppc32 binutils with > ppc64 support will make bfd_vma a long long). > > Alpha is 64bit only so it wouldnt have this problem. sparc64, parisc64 and > ppc64 do. try the attached patch. It's probably not sufficient but it's required. If it don't work I need more feedback where vma are truncated, send me typical -V output for a truncated address regards, Phil |
From: John L. <le...@mo...> - 2003-01-27 17:17:36
|
On Mon, Jan 27, 2003 at 12:03:03PM -0500, William Cohen wrote: > 2003-01-27 Will Cohen <wc...@re...> > > * daemon/opd_cookie.h(opd_nr_lookup_dcookie): Add ia64 version. > > Okay to check in? Yes. thanks john -- "In the crack house, as on the battlefield, breeding tells." - William Donaldson |
From: William C. <wc...@nc...> - 2003-01-27 17:04:18
|
Friday I got an ia64 kernel to use the new oprofile kernel interface. This is on a kernel Red Hat uses for AS 2.1. I want to generate an expanded version of the 2.4.20 patch to include support for the ia64. Right now the patched kernel only provides TIMER_INT support and not performance monitoring support. So there is some additional work required on the kernel patch. I found that that the oprofile cvs compiles out of the box on my ia64 machine with one exception for the lookup_dcookie. I have attached the patch which adds the appropriate entry for the ia64, so it will compile. 2003-01-27 Will Cohen <wc...@re...> * daemon/opd_cookie.h(opd_nr_lookup_dcookie): Add ia64 version. Okay to check in? -Will |
From: Anton B. <an...@sa...> - 2003-01-27 12:24:57
|
> >I just got around to trying oprofile cvs and indeed it does work with > >ppc32 userspace and ppc64 kernel. Nice work. > > > >Does op_to_source work on x86? It isnt working for me and I went through > |^^^^^^^^^^^^^^^| > it works on x86, what means ? --+ Running a ppc32 oprofile executable on a ppc64 kernel. (ie 32bit executable, 64bit kernel). When I run with -V op_to_source shows all the function offsets have the top 32 bits truncated. > Falk Hueffner report it works on alpha (at least results seems sensible) I had a word with Alan Modra and there could be interesting things going on with bfd. Apparently on 32bit hosts, bfd_vma can be either a long or long long depending on how its compiled (eg compiling ppc32 binutils with ppc64 support will make bfd_vma a long long). Alpha is 64bit only so it wouldnt have this problem. sparc64, parisc64 and ppc64 do. Anton |
From: Philippe E. <ph...@wa...> - 2003-01-27 12:06:18
|
Anton Blanchard wrote: > Hi John >>The post-profile userspace should hopefully be OK now (maybe some little >>bits left) > > > I just got around to trying oprofile cvs and indeed it does work with > ppc32 userspace and ppc64 kernel. Nice work. > > Does op_to_source work on x86? It isnt working for me and I went through |^^^^^^^^^^^^^^^| it works on x86, what means ? --+ > and started changing some of the u32's to vma_t's but still no luck. > Falk Hueffner report it works on alpha (at least results seems sensible) regards, Phil |
From: Anton B. <an...@sa...> - 2003-01-27 07:39:53
|
Hi John > This is a step forward even if there's some niggles. It's untested so it > would be good if people could try it out with latest CVS, especially on > 64-bit or 64/32 machines :) > > Note that we're still storing only unsigned longs in the hash table, but > as this is an offset I think it should be ok. > > The post-profile userspace should hopefully be OK now (maybe some little > bits left) I just got around to trying oprofile cvs and indeed it does work with ppc32 userspace and ppc64 kernel. Nice work. Does op_to_source work on x86? It isnt working for me and I went through and started changing some of the u32's to vma_t's but still no luck. Anton |
From: William C. <wc...@nc...> - 2003-01-24 17:16:59
|
Actually, it's ppc64 support in the 2.5 kernel. I haven't seen the associated oprofile support in the arch/ppc directory of the 2.5 kernels. -Will Philippe Elie wrote: > Beilloin, David wrote: > >> Hello, >> >> I had a look at the cvs tree and didn't find any file about PPC support. >> I use the following link, maybe I miss something ? >> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/oprofile/oprofile/module/ >> Does someone can point me to the right place ? or tell me How to find >> it ? > > > support doesn't exist for 2.4 you can find initial support > for ppc in 2.5 tree. I dunno at all if this is stable. Porting > to 2.4 can be difficult cause you need to write syscall wrapper. > > You need also a patch to user space tools, Anton Blanchard, > should know where it is available. Probably searching kernel > mail list will help. > > regards, > Phil > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: William C. <wc...@nc...> - 2003-01-24 16:05:39
|
The ppc64 just uses the timer interrupt mechanism, so it doesn't have a unique identifier for the cpu, so no change should be required for the userspace oprofile. For the alpha processors oprofile support makes use of the performance monitoring hardware and a patch is needed for the user space oprofile. -Will John Levon wrote: > On Fri, Jan 24, 2003 at 02:30:36PM +0000, Philippe Elie wrote: > > >>You need also a patch to user space tools, Anton Blanchard, >>should know where it is available. Probably searching kernel >>mail list will help. > > > Do we ? I don't think we need anything more > > There's no counter support after all > > regards > john |
From: John L. <le...@mo...> - 2003-01-24 15:46:27
|
On Fri, Jan 24, 2003 at 02:30:36PM +0000, Philippe Elie wrote: > You need also a patch to user space tools, Anton Blanchard, > should know where it is available. Probably searching kernel > mail list will help. Do we ? I don't think we need anything more There's no counter support after all regards john -- " It is quite humbling to realize that the storage occupied by the longest line from a typical Usenet posting is sufficient to provide a state space so vast that all the computation power in the world can not conquer it." - Dave Wallace |
From: Beilloin, D. <dbe...@mc...> - 2003-01-24 15:32:04
|
after a look to the 2.5 kernel tree, it seems right. As i never play with Linux2.5, and as a first step,=20 I'll have a look to the oprofile0.3 version for=20 kernel 2.4 to see the work to be done to make it work=20 on PowerPC... If someone has any hints, you are welcome. David. > -----Message d'origine----- > De : William Cohen [mailto:wc...@nc...] > Envoy=E9 : vendredi 24 janvier 2003 15:42 > =C0 : Philippe Elie > Cc : Beilloin, David; 'opr...@li...' > Objet : Re: oprofile PPC support >=20 >=20 > Actually, it's ppc64 support in the 2.5 kernel. I haven't seen the=20 > associated oprofile support in the arch/ppc directory of the=20 > 2.5 kernels. >=20 > -Will >=20 > Philippe Elie wrote: > > Beilloin, David wrote: > >=20 > >> Hello, > >> > >> I had a look at the cvs tree and didn't find any file=20 > about PPC support. > >> I use the following link, maybe I miss something ? > >>=20 > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/oprofile/oprofi le/module/ >> Does someone can point me to the right place ? or tell me How to = find=20 >> it ? >=20 >=20 > support doesn't exist for 2.4 you can find initial support > for ppc in 2.5 tree. I dunno at all if this is stable. Porting > to 2.4 can be difficult cause you need to write syscall wrapper. >=20 > You need also a patch to user space tools, Anton Blanchard, > should know where it is available. Probably searching kernel > mail list will help. >=20 > regards, > Phil >=20 >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 = See! > http://www.vasoftware.com > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list >=20 |
From: Philippe E. <ph...@wa...> - 2003-01-24 13:29:45
|
Beilloin, David wrote: > Hello, > > I had a look at the cvs tree and didn't find any file about PPC support. > I use the following link, maybe I miss something ? > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/oprofile/oprofile/module/ > Does someone can point me to the right place ? or tell me How to find it ? support doesn't exist for 2.4 you can find initial support for ppc in 2.5 tree. I dunno at all if this is stable. Porting to 2.4 can be difficult cause you need to write syscall wrapper. You need also a patch to user space tools, Anton Blanchard, should know where it is available. Probably searching kernel mail list will help. regards, Phil |
From: Beilloin, D. <dbe...@mc...> - 2003-01-24 09:48:32
|
Hello, I had a look at the cvs tree and didn't find any file about PPC = support. I use the following link, maybe I miss something ? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/oprofile/oprofile/module/= Does someone can point me to the right place ? or tell me How to find = it ? Nb: And sorry for the previous private email, I got a web access = problem=20 avoiding me to subscribe the list.. > -----Message d'origine----- > De : John Levon [mailto:le...@mo...] > Envoy=E9 : mercredi 22 janvier 2003 19:47 > =C0 : Beilloin, David > Cc : 'ph...@wa...' > Objet : Re: oprofile architecture support >=20 >=20 > On Wed, Jan 22, 2003 at 01:41:52PM -0500, Beilloin, David wrote: >=20 > > I would like to know if someone has already try to port the=20 > oprofile tools > > on PPC platform, and if not, what would be the complexity=20 > of doing so. >=20 > Current CVS should be fine. Anton Blanchard has been working=20 > on support. > >=20 > > Thanks in advance for your answer, > > and sorry to send this email directly to both of you. >=20 > Any reason you didn't use the mailing list ? >=20 > regards > john >=20 > --=20 > " It is quite humbling to realize that the storage occupied=20 > by the longest line > from a typical Usenet posting is sufficient to provide a=20 > state space so vast > that all the computation power in the world can not conquer it." > - Dave Wallace >=20 |
From: graydon h. <gr...@re...> - 2003-01-24 04:12:06
|
On Thu, 2003-01-23 at 16:10, John Levon wrote: > > I am going to release 0.5 on Wednesday 29th. I have punted p4 HT on 2.4, > and the ABI breakage. If anyone wants to fix either, or any other bugs, > they should be posted to the list by Tuesday. sorry I haven't been too responsive here recently; the work on packaging oprofile just right for our current release cycle has been rather time-consuming. I'll try to post some coherent bits on these items soon; probably not before tuesday though. -graydon |