|
From: John S. <joh...@ya...> - 2006-03-07 17:36:29
|
Hi, I have been trying to run my code under valgrind for memory leaks. Have been cross compiling on Red Hat Linux with Monta Vista to cross compile for ppc32 target. However I am getting the following error: WARNING: unhandled syscallL 72 You may be able to write your own handler. Read the file README_MISSING_SYSCALL_OR_IOCTL Tried to read the above file and implement on my own, but got lost on the way. Can anyone help? Thanks, John --------------------------------- Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze. |
|
From: Bart V. A. <bar...@gm...> - 2006-03-14 18:01:20
|
Hello John,
I'm using Valgrind 3.1.0 with MontaVista Linux Professional 3.1
and it works great. Note: I compiled Valgrind natively -- cross
compiling Valgrind does not work.
On 3/7/06, John Sensale <joh...@ya...> wrote:
>
> Hi,
> I have been trying to run my code under valgrind for memory leaks. Have b=
een
> cross compiling on Red Hat Linux with Monta Vista to cross compile for pp=
c32
> target. However I am getting the following error:
> WARNING: unhandled syscallL 72
> You may be able to write your own handler.
> Read the file README_MISSING_SYSCALL_OR_IOCTL
> Tried to read the above file and implement on my own, but got lost on the
> way.
> Can anyone help?
|
|
From: Benjamin C. <ben...@si...> - 2006-03-28 12:21:14
Attachments:
benjamin.collar.vcf
|
Hi I know this is a bit of an old mail, but I'm using MV CGE 3.1 and 4.0 for powerpc's 440 and 970. Cross compiling valgrind is certainly possible. I'm building on a pentium4 and running on the two different PPC's. (but then after a bit I get a crash, doh! anyway...) Ben Bart Van Assche wrote: > Hello John, > > I'm using Valgrind 3.1.0 with MontaVista Linux Professional 3.1 > and it works great. Note: I compiled Valgrind natively -- cross > compiling Valgrind does not work. > > On 3/7/06, John Sensale <joh...@ya...> wrote: > >>Hi, >>I have been trying to run my code under valgrind for memory leaks. Have been >>cross compiling on Red Hat Linux with Monta Vista to cross compile for ppc32 >>target. However I am getting the following error: >>WARNING: unhandled syscallL 72 >>You may be able to write your own handler. >>Read the file README_MISSING_SYSCALL_OR_IOCTL >>Tried to read the above file and implement on my own, but got lost on the >>way. >>Can anyone help? > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <to...@co...> - 2006-03-28 13:04:05
Attachments:
valgrind-sigsuspend.patch
|
In message <442...@si...>
Benjamin Collar <ben...@si...> wrote:
> I know this is a bit of an old mail, but I'm using MV CGE 3.1 and 4.0
> for powerpc's 440 and 970. Cross compiling valgrind is certainly
> possible. I'm building on a pentium4 and running on the two different
> PPC's. (but then after a bit I get a crash, doh! anyway...)
Try the attached patch - it is against the current SVN revision and
implements sigsuspend for x86 and ppc32. It is completely untested on
both platforms - I don't have a ppc box to try it on anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Benjamin C. <ben...@si...> - 2006-03-28 13:11:55
Attachments:
benjamin.collar.vcf
|
Thanks Tom, I will give that a try.
Currently, though, the crash comes from the fact that syscall 14 (mknod)
is not implemented :(
Ben
Tom Hughes wrote:
> In message <442...@si...>
> Benjamin Collar <ben...@si...> wrote:
>
>
>>I know this is a bit of an old mail, but I'm using MV CGE 3.1 and 4.0
>>for powerpc's 440 and 970. Cross compiling valgrind is certainly
>>possible. I'm building on a pentium4 and running on the two different
>>PPC's. (but then after a bit I get a crash, doh! anyway...)
>
>
> Try the attached patch - it is against the current SVN revision and
> implements sigsuspend for x86 and ppc32. It is completely untested on
> both platforms - I don't have a ppc box to try it on anyway.
>
> Tom
>
>
>
> ------------------------------------------------------------------------
>
> Index: coregrind/m_syswrap/syswrap-generic.c
> ===================================================================
> --- coregrind/m_syswrap/syswrap-generic.c (revision 5796)
> +++ coregrind/m_syswrap/syswrap-generic.c (working copy)
> @@ -5290,24 +5290,6 @@
> PRE_REG_READ0(long, "pause");
> }
>
> -//zz // XXX: x86-specific
> -//zz PRE(sys_sigsuspend, SfMayBlock)
> -//zz {
> -//zz /* The C library interface to sigsuspend just takes a pointer to
> -//zz a signal mask but this system call has three arguments - the first
> -//zz two don't appear to be used by the kernel and are always passed as
> -//zz zero by glibc and the third is the first word of the signal mask
> -//zz so only 32 signals are supported.
> -//zz
> -//zz In fact glibc normally uses rt_sigsuspend if it is available as
> -//zz that takes a pointer to the signal mask so supports more signals.
> -//zz */
> -//zz PRINT("sys_sigsuspend ( %d, %d, %d )", ARG1,ARG2,ARG3 );
> -//zz PRE_REG_READ3(int, "sigsuspend",
> -//zz int, history0, int, history1,
> -//zz vki_old_sigset_t, mask);
> -//zz }
> -
> // XXX: x86-specific
> PRE(sys_sigaltstack)
> {
> Index: coregrind/m_syswrap/priv_syswrap-generic.h
> ===================================================================
> --- coregrind/m_syswrap/priv_syswrap-generic.h (revision 5796)
> +++ coregrind/m_syswrap/priv_syswrap-generic.h (working copy)
> @@ -170,7 +170,6 @@
>
> // For the remainder, not really sure yet
> DECL_TEMPLATE(generic, sys_ptrace); // (x86?) (almost-P)
> -DECL_TEMPLATE(generic, sys_sigsuspend); // POSIX, but L (proto varies across archs)
> DECL_TEMPLATE(generic, sys_setrlimit); // SVr4, 4.3BSD
> DECL_TEMPLATE(generic, sys_ioctl); // x86? (various)
> DECL_TEMPLATE(generic, sys_old_getrlimit); // SVr4, 4.3BSD L?
> Index: coregrind/m_syswrap/syswrap-x86-linux.c
> ===================================================================
> --- coregrind/m_syswrap/syswrap-x86-linux.c (revision 5796)
> +++ coregrind/m_syswrap/syswrap-x86-linux.c (working copy)
> @@ -772,6 +772,7 @@
> DECL_TEMPLATE(x86_linux, sys_get_thread_area);
> DECL_TEMPLATE(x86_linux, sys_ptrace);
> DECL_TEMPLATE(x86_linux, sys_sigaction);
> +DECL_TEMPLATE(x86_linux, sys_sigsuspend);
> DECL_TEMPLATE(x86_linux, old_select);
> DECL_TEMPLATE(x86_linux, sys_vm86old);
> DECL_TEMPLATE(x86_linux, sys_vm86);
> @@ -1694,6 +1695,24 @@
> POST_MEM_WRITE( ARG3, sizeof(struct vki_old_sigaction));
> }
>
> +PRE(sys_sigsuspend)
> +{
> + /* The C library interface to sigsuspend just takes a pointer to
> + a signal mask but this system call has three arguments - the first
> + two don't appear to be used by the kernel and are always passed as
> + zero by glibc and the third is the first word of the signal mask
> + so only 32 signals are supported.
> +
> + In fact glibc normally uses rt_sigsuspend if it is available as
> + that takes a pointer to the signal mask so supports more signals.
> + */
> + *flags |= SfMayBlock;
> + PRINT("sys_sigsuspend ( %d, %d, %d )", ARG1,ARG2,ARG3 );
> + PRE_REG_READ3(int, "sigsuspend",
> + int, history0, int, history1,
> + vki_old_sigset_t, mask);
> +}
> +
> PRE(sys_vm86old)
> {
> PRINT("sys_vm86old ( %p )", ARG1);
> @@ -1863,7 +1882,7 @@
> //zz
> LINX_(__NR_setreuid, sys_setreuid16), // 70
> LINX_(__NR_setregid, sys_setregid16), // 71
> -//zz GENX_(__NR_sigsuspend, sys_sigsuspend), // 72
> + PLAX_(__NR_sigsuspend, sys_sigsuspend), // 72
> LINXY(__NR_sigpending, sys_sigpending), // 73
> //zz // (__NR_sethostname, sys_sethostname), // 74 */*
> //zz
> Index: coregrind/m_syswrap/syswrap-ppc32-linux.c
> ===================================================================
> --- coregrind/m_syswrap/syswrap-ppc32-linux.c (revision 5796)
> +++ coregrind/m_syswrap/syswrap-ppc32-linux.c (working copy)
> @@ -392,6 +392,7 @@
> DECL_TEMPLATE(ppc32_linux, sys_sigreturn);
> DECL_TEMPLATE(ppc32_linux, sys_rt_sigreturn);
> DECL_TEMPLATE(ppc32_linux, sys_sigaction);
> +DECL_TEMPLATE(ppc32_linux, sys_sigsuspend);
>
> PRE(sys_socketcall)
> {
> @@ -1424,7 +1425,21 @@
> POST_MEM_WRITE( ARG3, sizeof(struct vki_old_sigaction));
> }
>
> +PRE(sys_sigsuspend)
> +{
> + /* The C library interface to sigsuspend just takes a pointer to
> + a signal mask but this system call only takes the first word of
> + the signal mask as an argument so only 32 signals are supported.
> +
> + In fact glibc normally uses rt_sigsuspend if it is available as
> + that takes a pointer to the signal mask so supports more signals.
> + */
> + *flags |= SfMayBlock;
> + PRINT("sys_sigsuspend ( %d )", ARG1 );
> + PRE_REG_READ1(int, "sigsuspend", vki_old_sigset_t, mask);
> +}
>
> +
> #undef PRE
> #undef POST
>
> @@ -1531,7 +1546,7 @@
> //..
> //.. LINX_(__NR_setreuid, sys_setreuid16), // 70
> //.. LINX_(__NR_setregid, sys_setregid16), // 71
> -//.. GENX_(__NR_sigsuspend, sys_sigsuspend), // 72
> + PLAX_(__NR_sigsuspend, sys_sigsuspend), // 72
> //.. LINXY(__NR_sigpending, sys_sigpending), // 73
> //.. // (__NR_sethostname, sys_sethostname), // 74 */*
> //..
|
|
From: Tom H. <to...@co...> - 2006-03-28 13:17:51
|
In message <442...@si...>
Benjamin Collar <ben...@si...> wrote:
> Thanks Tom, I will give that a try.
>
> Currently, though, the crash comes from the fact that syscall 14
> (mknod) is not implemented :(
The message you quoted said syscall 72 so that is what I implemented...
I was a bit surprised as glibc will normally use sys_rt_sigsuspend
in preference to sys_sigsuspend.
Syscall 14 is easy - just uncomment it in syswrap-ppc32-linux.c and
it should work with the generic handler that already exists.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Benjamin C. <ben...@si...> - 2006-04-03 13:25:59
Attachments:
benjamin.collar.vcf
|
Hi Tom Thanks for the patch you sent me for syscall 72. The patch itself wouldn't apply against the SVN version I had (wrong hour to pull it, I guess), but I applied it manually against 3.1.1 and also added the syscall 14 change. The result is that everything looks happy. I don't receive crashes related to syscall 72 nor 14 anymore. I've only tested this on a ppc32 so far. Thanks much! Ben Tom Hughes wrote: > In message <442...@si...> > Benjamin Collar <ben...@si...> wrote: > > > Thanks Tom, I will give that a try. > > > > Currently, though, the crash comes from the fact that syscall 14 > > (mknod) is not implemented :( > > The message you quoted said syscall 72 so that is what I implemented... > > I was a bit surprised as glibc will normally use sys_rt_sigsuspend > in preference to sys_sigsuspend. > > Syscall 14 is easy - just uncomment it in syswrap-ppc32-linux.c and > it should work with the generic handler that already exists. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642> > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bart V. A. <bar...@gm...> - 2006-03-29 23:06:24
|
Hello Benjamin, I also succeeded now at cross-compiling valgrind, but this only succeeds when specifying --enable-tls as a configure argument. Maybe this is something that can be added to the valgrind FAQ ? On 3/28/06, Benjamin Collar <ben...@si...> wrote: > > Hi > > I know this is a bit of an old mail, but I'm using MV CGE 3.1 and 4.0 > for powerpc's 440 and 970. Cross compiling valgrind is certainly > possible. I'm building on a pentium4 and running on the two different > PPC's. (but then after a bit I get a crash, doh! anyway...) > |
|
From: Julian S. <js...@ac...> - 2006-03-18 13:30:10
|
On Tuesday 14 March 2006 18:01, Bart Van Assche wrote: > Hello John, > > I'm using Valgrind 3.1.0 with MontaVista Linux Professional 3.1 > and it works great. Did you try 3.1.1 ? I'm hoping I didn't break anything in the 3.1.0 -> 3.1.1 transition, and there are some worthwhile ppc32 fixes in 3.1.1. J |
|
From: Bart V. A. <bar...@gm...> - 2006-03-19 17:54:35
|
On 3/18/06, Julian Seward <js...@ac...> wrote: > > On Tuesday 14 March 2006 18:01, Bart Van Assche wrote: > > I'm using Valgrind 3.1.0 with MontaVista Linux Professional 3.1 > > and it works great. > > Did you try 3.1.1 ? I'm hoping I didn't break anything in the > 3.1.0 -> 3.1.1 transition, and there are some worthwhile ppc32 > fixes in 3.1.1. > We are migrating from MontaVista Linux Professional 3.1 to 4.0 (2.6 kernel)= . Maybe there will be some time to deploy Valgrind 3.1.1 after that transition. |
|
From: Benjamin C. <ben...@si...> - 2006-03-29 08:24:11
Attachments:
benjamin.collar.vcf
|
Hi Bart That's funny, because it only succeeded for me when I have --disable-tls. It was months ago when I discovered that this was necessary, and since then have forgotten why. My configure looks like this: CXX='$(C++)' CC='$(CC)' AR='$(AR)' LD='$(LD)' NM='$(NM)' ./configure --prefix=$(INSTDIR) --disable-tls --host powerpc-unknown-linux I think the decision to enable or disable tls depends on the configuration of the libc valgrind is compiled against/will be running on. But I could be wrong. Benjamin Bart Van Assche wrote: > Hello Benjamin, > > I also succeeded now at cross-compiling valgrind, but this only > succeeds when specifying --enable-tls as a configure argument. Maybe > this is something that can be added to the valgrind FAQ ? > > On 3/28/06, *Benjamin Collar* <ben...@si... > <mailto:ben...@si...>> wrote: > > Hi > > I know this is a bit of an old mail, but I'm using MV CGE 3.1 and 4.0 > for powerpc's 440 and 970. Cross compiling valgrind is certainly > possible. I'm building on a pentium4 and running on the two different > PPC's. (but then after a bit I get a crash, doh! anyway...) > > |
|
From: Bart V. A. <bar...@gm...> - 2006-03-29 15:30:51
|
Hello Benjamin,
I should have been more precise in my statement: depending on the targe=
t
either --enable-tls or --disable-tls should be specified -- the test for
automatically detecting whether TLS support is available makes ./configure
abort.
On 3/29/06, Benjamin Collar <ben...@si...> wrote:
>
> Hi Bart
>
> That's funny, because it only succeeded for me when I have
> --disable-tls. It was months ago when I discovered that this was
> necessary, and since then have forgotten why. My configure looks like
> this:
>
> CXX=3D'$(C++)' CC=3D'$(CC)' AR=3D'$(AR)' LD=3D'$(LD)' NM=3D'$(NM)' ./conf=
igure
> --prefix=3D$(INSTDIR) --disable-tls --host powerpc-unknown-linux
>
> I think the decision to enable or disable tls depends on the
> configuration of the libc valgrind is compiled against/will be running
> on. But I could be wrong.
>
> Benjamin
>
> Bart Van Assche wrote:
> > Hello Benjamin,
> >
> > I also succeeded now at cross-compiling valgrind, but this only
> > succeeds when specifying --enable-tls as a configure argument. Maybe
> > this is something that can be added to the valgrind FAQ ?
> >
> > On 3/28/06, *Benjamin Collar* <ben...@si...
> > <mailto:ben...@si...>> wrote:
> >
> > Hi
> >
> > I know this is a bit of an old mail, but I'm using MV CGE 3.1 and
> 4.0
> > for powerpc's 440 and 970. Cross compiling valgrind is certainly
> > possible. I'm building on a pentium4 and running on the two
> different
> > PPC's. (but then after a bit I get a crash, doh! anyway...)
>
|
|
From: Tom H. <to...@co...> - 2006-03-29 23:15:54
|
In message <e2e...@ma...>
"Bart Van Assche" <bar...@gm...> wrote:
> I also succeeded now at cross-compiling valgrind, but this only succeeds
> when specifying --enable-tls as a configure argument. Maybe this is
> something that can be added to the valgrind FAQ ?
That seems very odd - all that does is cause HAVE_TLS to be defined
and that only effects a couple of tests. It has no effect on valgrind
itself. What is the problem you see if you don't use it?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bart V. A. <bar...@gm...> - 2006-03-30 16:38:54
|
Hello Tom,
The following error message is printed when cross-configuring without
specifying --enable-tls or --disable-tls:
checking for TLS support... configure: error: cannot run test program while
cross compiling
See `config.log' for more details.
On 3/30/06, Tom Hughes <to...@co...> wrote:
>
> In message <e2e...@ma...>
> "Bart Van Assche" <bar...@gm...> wrote:
>
> > I also succeeded now at cross-compiling valgrind, but this only
> succeeds
> > when specifying --enable-tls as a configure argument. Maybe this is
> > something that can be added to the valgrind FAQ ?
>
> That seems very odd - all that does is cause HAVE_TLS to be defined
> and that only effects a couple of tests. It has no effect on valgrind
> itself. What is the problem you see if you don't use it?
>
|
|
From: Tom H. <to...@co...> - 2006-03-30 14:01:03
|
In message <e2e...@ma...>
Bart Van Assche <bar...@gm...> wrote:
> The following error message is printed when cross-configuring without
> specifying --enable-tls or --disable-tls:
>
> checking for TLS support... configure: error: cannot run test program while
> cross compiling
> See `config.log' for more details.
Ah, so the problem is that configure fails - even though the result
of that test is only needed for the test suite.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|