|
From: ZhangPu <zh...@fj...> - 2005-02-09 11:14:44
|
Hello How can I compile the valgrind-2.2.0 on a ia64 machine? Thank you Pu |
|
From: Nicholas N. <nj...@cs...> - 2005-02-09 19:17:43
|
On Wed, 9 Feb 2005, ZhangPu wrote: > How can I compile the valgrind-2.2.0 on a ia64 machine? You can't. Valgrind is currently x86-only, and ia64 support is very unlikely to occur any time soon. N |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 04:28:49
|
Thanks for your answer. > You can't. Valgrind is currently x86-only, and ia64 support is very > unlikely to occur any time soon. But from the http://fedora.server4you.net/fedora/core/development/ia64/SRPMS/ a valgrind-2.2.0-8.src.rpm package which includes some patchs was supplied yesterday. It seemed like this one can be worked on ia64. Did sb. compile this successfully? On my machine, I cannot clear make error. If sb. compiled it, would you please paste your steps on this mailing list? Pu |
|
From: Robert W. <rj...@du...> - 2005-02-10 04:52:10
|
> But from the http://fedora.server4you.net/fedora/core/development/ia64/SR= PMS/ > a valgrind-2.2.0-8.src.rpm package which includes some patchs was supplie= d=20 > yesterday. >=20 > It seemed like this one can be worked on ia64.=20 Looks to me like the stock Valgrind 2.2.0 source RPM with some useful non-arch-specific patches attached. There's nothing in there to port it to IA64, though. There's no corresponding RPM file in the Fedora/RPMS directory either, so they didn't build it. They probably just grabbed all the stock Fedora source RPMS, stuck them in there and ported what they could. Valgrind isn't going to be running on IA64 any time soon. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 05:00:16
|
So what can I do? I want to test memory leak for our ia64 application. Do you know other tool can be used on ia64? Thanks & Regards Pu On Wed, 09 Feb 2005 20:52:04 -0800 Robert Walsh <rj...@du...> wrote: > > But from the http://fedora.server4you.net/fedora/core/development/ia64/SRPMS/ > > a valgrind-2.2.0-8.src.rpm package which includes some patchs was supplied > > yesterday. > > > > It seemed like this one can be worked on ia64. > > Looks to me like the stock Valgrind 2.2.0 source RPM with some useful > non-arch-specific patches attached. There's nothing in there to port it > to IA64, though. There's no corresponding RPM file in the Fedora/RPMS > directory either, so they didn't build it. They probably just grabbed > all the stock Fedora source RPMS, stuck them in there and ported what > they could. > > Valgrind isn't going to be running on IA64 any time soon. > > Regards, > Robert. > > -- > Robert Walsh > Amalgamated Durables, Inc. - "We don't make the things you buy." > Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2005-02-10 05:15:31
|
> So what can I do? I want to test memory leak for our ia64 application.=20 > Do you know other tool can be used on ia64?=20 Sorry - I can't think of any. You might want to try porting to x86 and testing there, but it won't be perfect. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Howard C. <hy...@sy...> - 2005-02-10 05:38:53
|
Robert Walsh wrote: >>So what can I do? I want to test memory leak for our ia64 application. >>Do you know other tool can be used on ia64? >> >> > >Sorry - I can't think of any. You might want to try porting to x86 and >testing there, but it won't be perfect. > I think FunctionCheck should work. I have an update to correct some int/long portability issues I encountered on an x86_64 test, still need to get that posted onto my web site. (See the HighlandSun link in my .sig...) -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 06:36:58
|
Thanks for you supplied this tool. I'm compiling it now. But I got the error fllowing when did 'make': fncmalloc.c: In function `hx_init_malloc': fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function) fncmalloc.c:34: error: (Each undeclared identifier is reported only once fncmalloc.c:34: error: for each function it appears in.) checked dlfcn.h [isdev@ipf124 fnccheck]$ rpm -qf /usr/include/dlfcn.h glibc-headers-2.3.3-73 [isdev@ipf124 fnccheck]$ grep RTLD_NEXT /usr/include/* 2> /dev/null /usr/include/dlfcn.h:/* If the first argument of `dlsym' or `dlvsym' is set to RTLD_NEXT /usr/include/dlfcn.h:# define RTLD_NEXT ((void *) -1l) Any ideas? Thanks & Regards Pu On Wed, 09 Feb 2005 21:40:33 -0800 Howard Chu <hy...@sy...> wrote: > Robert Walsh wrote: > > >>So what can I do? I want to test memory leak for our ia64 application. > >>Do you know other tool can be used on ia64? > >> > >> > > > >Sorry - I can't think of any. You might want to try porting to x86 and > >testing there, but it won't be perfect. > > > I think FunctionCheck should work. I have an update to correct some > int/long portability issues I encountered on an x86_64 test, still need > to get that posted onto my web site. (See the HighlandSun link in my > .sig...) > > -- > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 06:51:52
|
/usr/include/dlfcn.h #ifdef __USE_GNU =2E.. # define RTLD_NEXT ((void *) -1l) =2E.. #endif Need a GNU make? On Thu, 10 Feb 2005 15:36:16 +0900 ZhangPu <zh...@fj...> wrote: >=20 > Thanks for you supplied this tool. > I'm compiling it now. >=20 > But I got the error fllowing when did 'make': > fncmalloc.c: In function `hx_init_malloc': > fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function= ) > fncmalloc.c:34: error: (Each undeclared identifier is reported only once > fncmalloc.c:34: error: for each function it appears in.) >=20 > checked dlfcn.h > [isdev@ipf124 fnccheck]$ rpm -qf /usr/include/dlfcn.h > glibc-headers-2.3.3-73 > [isdev@ipf124 fnccheck]$ grep RTLD_NEXT /usr/include/* 2> /dev/null > /usr/include/dlfcn.h:/* If the first argument of `dlsym' or `dlvsym' is s= et to RTLD_NEXT > /usr/include/dlfcn.h:# define RTLD_NEXT ((void *) -1l) >=20 > Any ideas? >=20 > Thanks & Regards > Pu > On Wed, 09 Feb 2005 21:40:33 -0800 > Howard Chu <hy...@sy...> wrote: >=20 > > Robert Walsh wrote: > >=20 > > >>So what can I do? I want to test memory leak for our ia64 application.= =20 > > >>Do you know other tool can be used on ia64?=20 > > >> =20 > > >> > > > > > >Sorry - I can't think of any. You might want to try porting to x86 an= d > > >testing there, but it won't be perfect. > > > > > I think FunctionCheck should work. I have an update to correct some=20 > > int/long portability issues I encountered on an x86_64 test, still need= =20 > > to get that posted onto my web site. (See the HighlandSun link in my=20 > > .sig...) > >=20 > > --=20 > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > http://www.symas.com http://highlandsun.com/hyc > > Symas: Premier OpenSource Development and Support >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Howard C. <hy...@sy...> - 2005-02-10 07:00:58
|
ZhangPu wrote: >/usr/include/dlfcn.h >#ifdef __USE_GNU >... ># define RTLD_NEXT ((void *) -1l) >... >#endif > >Need a GNU make? > > No, but you need to add "-D__USE_GNU" to the CFLAGS, I think. On older versions of glibc it was defined by default, not sure when/why it changed. Most of the autoconf machinery in this package is pretty broken. It was like that in the original FunctionCheck 1.4 and I've never bothered to fix it, since I was only interested in getting it to work for myself on Linux and Solaris. Also the test directory is broken, I never use it. It has tests for C and C++, but I've only used this tool for C. (assert( C > C++) ;) >On Thu, 10 Feb 2005 15:36:16 +0900 >ZhangPu <zh...@fj...> wrote: > > > >>Thanks for you supplied this tool. >>I'm compiling it now. >> >>But I got the error fllowing when did 'make': >>fncmalloc.c: In function `hx_init_malloc': >>fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function) >>fncmalloc.c:34: error: (Each undeclared identifier is reported only once >>fncmalloc.c:34: error: for each function it appears in.) >> >>checked dlfcn.h >>[isdev@ipf124 fnccheck]$ rpm -qf /usr/include/dlfcn.h >>glibc-headers-2.3.3-73 >>[isdev@ipf124 fnccheck]$ grep RTLD_NEXT /usr/include/* 2> /dev/null >>/usr/include/dlfcn.h:/* If the first argument of `dlsym' or `dlvsym' is set to RTLD_NEXT >>/usr/include/dlfcn.h:# define RTLD_NEXT ((void *) -1l) >> >>Any ideas? >> >>Thanks & Regards >>Pu >>On Wed, 09 Feb 2005 21:40:33 -0800 >>Howard Chu <hy...@sy...> wrote: >> >> > > > > -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: ZhangPu <zh...@fj...> - 2005-02-14 09:14:38
|
> No, but you need to add "-D__USE_GNU" to the CFLAGS, I think. On older > versions of glibc it was defined by default, not sure when/why it changed. Today, I compiled this tool again with CFLAGS, but same error still occurred. > >>fncmalloc.c: In function `hx_init_malloc': > >>fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function) > >>fncmalloc.c:34: error: (Each undeclared identifier is reported only once > >>fncmalloc.c:34: error: for each function it appears in.) regards Pu |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-02-10 09:03:07
|
Hi, > So what can I do? I want to test memory leak for our ia64 application. > Do you know other tool can be used on ia64? Insure++ supports on AMD64 and Intel EM64T processors. http://www.parasoft.com/ Purify has no specific hardware requirements so it should work on your platform: http://www-306.ibm.com/software/awdtools/purify/ http://www-306.ibm.com/software/awdtools/purifyplus/ Dimitri |
|
From: Tom H. <to...@co...> - 2005-02-10 09:17:53
|
In message <420...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> Hi,
>
>> So what can I do? I want to test memory leak for our ia64
>> application. Do you know other tool can be used on ia64?
>
>
> Insure++ supports on AMD64 and Intel EM64T processors.
> http://www.parasoft.com/
But IA64 is Itanium which is completely different to AMD64/EMT64T.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-02-10 15:33:03
|
> > Insure++ supports on AMD64 and Intel EM64T processors. > > But IA64 is Itanium which is completely different to AMD64/EMT64T. Insure++ also has a beta build for Linux/IA64 and an official distribution for HP-UX 11.23/ia64. However, from here it appears that Itanic has really gone under: there is almost complete lack of customer interest in either HP11/ia64 or Linux/ia64 support. > Purify has no specific hardware requirements so it should work on your platform: Now that is a truly amazing statement. Purify (AFAIK) works only on SPARC, MIPS, PA-RISC, and (recently) x86 processors. |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-02-10 15:41:53
|
> Now that is a truly amazing statement. > Purify (AFAIK) works only on SPARC, MIPS, PA-RISC, and (recently) x86 > processors. Yes, I was also surpized since they instrument object code. I was mislead by the advertized system requirements for PurifyPlus which on second thought are obviously wrong: http://www-306.ibm.com/software/awdtools/purifyplus/sysreq/ I guess the person who wrote this page thought PurifyPlus relies on Purify which does have strict system requirements: http://www-306.ibm.com/software/awdtools/purify/sysreq/ Dimitri |
|
From: Banibrata D. <du...@in...> - 2005-02-11 08:03:35
|
Hi Paul, > Insure++ also has a beta build for Linux/IA64 and an official > distribution for HP-UX 11.23/ia64. > > However, from here it appears that Itanic has really gone > under: there is almost complete lack of customer interest in > either HP11/ia64 or > Linux/ia64 support. What makes you think that Itanium (if that's what you meant by Itanic) has gone under ? It's alive and kickin', look at HP's Superdome sales !! > > Purify has no specific hardware requirements so it should > work on your platform: > > Now that is a truly amazing statement. > Purify (AFAIK) works only on SPARC, MIPS, PA-RISC, and > (recently) x86 processors. Well, if they switch to pure "Source instrumentation" as against object-instrumentation, the can be almost platform agnostic. my 2 cents, Banibrata Dutta. |
|
From: Nicholas N. <nj...@cs...> - 2005-02-10 14:38:53
|
On Thu, 10 Feb 2005, Dimitri Papadopoulos-Orfanos wrote: >> So what can I do? I want to test memory leak for our ia64 application. Do >> you know other tool can be used on ia64? > > Insure++ supports on AMD64 and Intel EM64T processors. > http://www.parasoft.com/ > > Purify has no specific hardware requirements so it should work on your > platform: > http://www-306.ibm.com/software/awdtools/purify/ > http://www-306.ibm.com/software/awdtools/purifyplus/ Pin (rogue.colorado.edu/Pin/) is a dynamic binary instrumentation framework that works on ia64, ia32 and amd64. I don't think it has a memory leak detector, but it would be a good framework for building one :) N |