|
From: Hiren G. <hir...@ya...> - 2008-10-06 12:16:18
Attachments:
Valgrind-3.3.1_output.txt
|
Hi All,
I have cross-compiled Valgrind 3.3.1 to run on MontaVista Linux 2.6.10 on CPU e500. However, when I try to run valgrind, I got the error as mentioned in the attached Valgrind-3.3.1_output.txt file. I have used build system as RHEL 4 (Kernel 2.6.10) with gcc 3.3.1
Could anyone please help me out with this?
Before arriving on this error, I had issue with isel instruction and which was solved by the description (plus the code given) for the BUG ID: 160954 and for which I have put the fix in guest-ppc/toIR.c file. I was wondering if the fix was fine, why it didn't get into the SVN?
CPU INFO
--------
processor : 0
cpu : e500
revision : 2.0 (pvr 8020 0020)
bogomips : 665.60
chipset : 8555E
Machine : CDA-911 - MPC8555E (10)
Boot bank : Normal
Boot level : 0xdc
Reset factor : 0x0
clock : 666MHz
PVR : 0x80200020
SVR : 0x80790011
PLL setting : 0x4
Memory : 512 MB
Output of objdump -d ld-2.3.3.so file where the error has been shown (vmhaddshs - I guess so).
0000c254 <_dl_catch_error>:
c254: 94 21 fd 50 stwu r1,-688(r1)
c258: 7c 08 02 a6 mflr r0
c25c: 39 c0 02 98 li r14,664
c260: 48 01 bd a1 bl 28000 <_DYNAMIC+0xbc>
c264: 13 c1 73 20 vmhaddshs v30,v1,v14,v12
c268: 39 c0 02 a0 li r14,672
c26c: 7f c8 02 a6 mflr r30
c270: 13 e1 73 20 vmhaddshs v31,v1,v14,v12
c274: 81 3e 07 04 lwz r9,1796(r30)
c278: 90 01 02 b4 stw r0,692(r1)
c27c: 38 00 00 00 li r0,0
c280: 90 01 00 14 stw r0,20(r1)
c284: 90 81 02 74 stw r4,628(r1)
c288: 81 29 00 4c lwz r9,76(r9)
c28c: 90 a1 02 78 stw r5,632(r1)
c290: 90 c1 02 7c stw r6,636(r1)
c294: 7d 29 03 a6 mtctr r9
c298: 90 61 02 70 stw r3,624(r1)
c29c: 4e 80 04 21 bctrl
|
|
From: Julian S. <js...@ac...> - 2008-10-07 14:45:49
|
Hi. I did look into this problem a few months back. The difficulty is that supporting e500 is a lot more complex than merely making the isel instruction work. Once isel is fixed, you then run into this, as you observed > Output of objdump -d ld-2.3.3.so file where the error has been shown > (vmhaddshs - I guess so). > > 0000c254 <_dl_catch_error>: > c254: 94 21 fd 50 stwu r1,-688(r1) > c258: 7c 08 02 a6 mflr r0 > c25c: 39 c0 02 98 li r14,664 > c260: 48 01 bd a1 bl 28000 <_DYNAMIC+0xbc> > c264: 13 c1 73 20 vmhaddshs v30,v1,v14,v12 > c268: 39 c0 02 a0 li r14,672 > c26c: 7f c8 02 a6 mflr r30 > c270: 13 e1 73 20 vmhaddshs v31,v1,v14,v12 These appear to be e500 specific instructions which occupy the same decoding space as Altivec (vmhaddshs is an Altivec instruction, and it is complete nonsense for it to appear in this context). So fixing e500 support properly would require both adding support for some unknown number of new instructions, and also messing with the cpu capabilities stuff so as to know whether to decode such instructions as Altivec or e500 extensions. And, lacking access to any real e500 hardware, at that point my investigation simply stopped. J |
|
From: jaguar x. <xio...@gm...> - 2009-06-19 06:05:30
|
Hi,
This is quite an old topic, but I get exact the same problem. With
objdump -M e500x2, I think below is the "real" instruction
be6c: 94 21 fd 50 stwu r1,-688(r1)
be70: 7c 08 02 a6 mflr r0
be74: 39 c0 02 98 li r14,664
be78: 48 01 c1 89 bl 28000 <__libc_enable_secure+0xbc>
be7c: 13 c1 73 20 evstddx r30,r1,r14
be80: 39 c0 02 a0 li r14,672
be84: 7f c8 02 a6 mflr r30
be88: 13 e1 73 20 evstddx r31,r1,r14
Accoring to PowerISA and EREF, evstddx is an SPE APU. As I'm not
familiar with valgrind implementation, could you give me some info about
how to support these SPE APU extentions? One of them, of course, would
be decoding. :)
Jaguar
Julian Seward Wrote:
> Hi. I did look into this problem a few months back. The difficulty is that
> supporting e500 is a lot more complex than merely making the isel instruction
> work. Once isel is fixed, you then run into this, as you observed
>
>> Output of objdump -d ld-2.3.3.so file where the error has been shown
>> (vmhaddshs - I guess so).
>>
>> 0000c254 <_dl_catch_error>:
>> c254: 94 21 fd 50 stwu r1,-688(r1)
>> c258: 7c 08 02 a6 mflr r0
>> c25c: 39 c0 02 98 li r14,664
>> c260: 48 01 bd a1 bl 28000 <_DYNAMIC+0xbc>
>> c264: 13 c1 73 20 vmhaddshs v30,v1,v14,v12
>> c268: 39 c0 02 a0 li r14,672
>> c26c: 7f c8 02 a6 mflr r30
>> c270: 13 e1 73 20 vmhaddshs v31,v1,v14,v12
>
> These appear to be e500 specific instructions which occupy the same decoding
> space as Altivec (vmhaddshs is an Altivec instruction, and it is complete
> nonsense for it to appear in this context).
>
> So fixing e500 support properly would require both adding support for some
> unknown number of new instructions, and also messing with the cpu capabilities
> stuff so as to know whether to decode such instructions as Altivec or e500
> extensions. And, lacking access to any real e500 hardware, at that point
> my investigation simply stopped.
>
> J
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
|
|
From: Chris P. <jud...@gm...> - 2008-10-07 20:31:50
|
Hi, I have used valgrind (3.2.3 and 3.3.1) successfully on an embedded target with an e500 processor. My kernel, compiler and libraries are quite different to those reported but I just wanted to say that it works for me. Looking at my ld.so (uClibc implementation) there aren't any vmhaddshs instructions which may mean that my compiler (gcc 4.1.1 + patches) is not using the special e500 instructions or that uClibc doesn't. I'll double check my compiler flags to see if I'm compiling for e500 or just generic ppc but there may be a possible workaround. Has anyone got some example sourcode that compiles to use this instruction? On Wed, Oct 8, 2008 at 3:30 AM, Julian Seward <js...@ac...> wrote: > > Hi. I did look into this problem a few months back. The difficulty is > that > supporting e500 is a lot more complex than merely making the isel > instruction > work. Once isel is fixed, you then run into this, as you observed > > > Output of objdump -d ld-2.3.3.so file where the error has been shown > > (vmhaddshs - I guess so). > > > > 0000c254 <_dl_catch_error>: > > c254: 94 21 fd 50 stwu r1,-688(r1) > > c258: 7c 08 02 a6 mflr r0 > > c25c: 39 c0 02 98 li r14,664 > > c260: 48 01 bd a1 bl 28000 <_DYNAMIC+0xbc> > > c264: 13 c1 73 20 vmhaddshs v30,v1,v14,v12 > > c268: 39 c0 02 a0 li r14,672 > > c26c: 7f c8 02 a6 mflr r30 > > c270: 13 e1 73 20 vmhaddshs v31,v1,v14,v12 > > These appear to be e500 specific instructions which occupy the same > decoding > space as Altivec (vmhaddshs is an Altivec instruction, and it is complete > nonsense for it to appear in this context). > > So fixing e500 support properly would require both adding support for some > unknown number of new instructions, and also messing with the cpu > capabilities > stuff so as to know whether to decode such instructions as Altivec or e500 > extensions. And, lacking access to any real e500 hardware, at that point > my investigation simply stopped. > > J > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Michael P. <md...@tr...> - 2008-10-08 03:15:11
|
Chris Packham writes: > Hi, > > I have used valgrind (3.2.3 and 3.3.1) successfully on an embedded target with > an e500 processor. My kernel, compiler and libraries are quite different to > those reported but I just wanted to say that it works for me. > > Looking at my ld.so (uClibc implementation) there aren't any vmhaddshs > instructions which may mean that my compiler (gcc 4.1.1 + patches) is not using > the special e500 instructions or that uClibc doesn't. I'll double check my > compiler flags to see if I'm compiling for e500 or just generic ppc but there > may be a possible workaround. > > Has anyone got some example sourcode that compiles to use this instruction? I do not think I have source code that generates that particular instruction, but if your gcc was built to support the e500 Signal Processing Extensions (often called SPE, which nicely collides with a certain well-known Power architecture extension) and your assembler recognizes the mnemonics, you should be able to generate a number of them yourself by using the -mspe compiler flag on code that involves floating point operations. You might need a newer gcc than 4.1.x to generate all of the instructions for the e500v2 SPE; and some of them require non-standard calls rather than being generated by gcc's instruction patterns from standard C code. gcc provides an <spe.h> header file that helps applications make those non-standard calls. My guess is that your toolchain wasn't compiled to generate e500 SPE instructions by default, so it uses traditional Power FPU instructions (with kernel emulation) or plain software floating-point. The e500 SPE unit is obnoxious to software on a number of levels: it reuses AltiVec instruction space; it widens the GPRs (R0-R31) to 64 bits to use them as 64-bit-integer/64-bit-float/SIMD-32-bit-float-pair operands; it hijacks the AltiVec exception bit in the Machine Status Register to enable accesses to the top halves of the 64-bit-wide registers; *and* FreeScale says restrict it to libraries and device drivers because SPE will go away in future chips. The only advice I would have for Hiren Gajjar is that it should be possible to generate code that avoids using the SPE by consistently using the -mno-spe compiler flag. (Hopefully that is an acceptable solution, at least when using valgrind.) Michael Poole |
|
From: Nicholas N. <nj...@cs...> - 2008-10-12 19:26:15
|
On Tue, 7 Oct 2008, Michael Poole wrote: > The e500 SPE unit is obnoxious to software on a number of levels: it > reuses AltiVec instruction space; it widens the GPRs (R0-R31) to 64 > bits to use them as 64-bit-integer/64-bit-float/SIMD-32-bit-float-pair > operands; it hijacks the AltiVec exception bit in the Machine Status > Register to enable accesses to the top halves of the 64-bit-wide > registers; *and* FreeScale says restrict it to libraries and device > drivers because SPE will go away in future chips. Wow. That is obnoxious. N |
|
From: Hiren G. <hir...@ya...> - 2008-10-13 04:54:53
|
Hi Poole,
Thanks for the help. Sorry, I could understand bits and pieces here and there, but I couldn't follow what you mentioned 100% since, I lack knowledge of such low levels.
However, using -mno-spe might not work since, the issue is not in the APP code, but its in the LD. At first place, I did not know how that symbol is getting loaded in LD. Besides, I have tried compiling app with -mno-spe but it seems my compiler does not recognize it. Also, it won't be feasible for me to recompile whole tool-chain kit since, I do not have sources for the same.
Thanks & Regards,
Hiren
--- On Mon, 10/13/08, Nicholas Nethercote <nj...@cs...> wrote:
> From: Nicholas Nethercote <nj...@cs...>
> Subject: Re: [Valgrind-users] ppc e500 - declined to decode an AltiVec insn - vmhaddshs
> To: "Michael Poole" <md...@tr...>
> Cc: "Chris Packham" <jud...@gm...>, "Hiren Gajjar" <hir...@ya...>, val...@li...
> Date: Monday, October 13, 2008, 12:54 AM
> On Tue, 7 Oct 2008, Michael Poole wrote:
>
> > The e500 SPE unit is obnoxious to software on a number
> of levels: it
> > reuses AltiVec instruction space; it widens the GPRs
> (R0-R31) to 64
> > bits to use them as
> 64-bit-integer/64-bit-float/SIMD-32-bit-float-pair
> > operands; it hijacks the AltiVec exception bit in the
> Machine Status
> > Register to enable accesses to the top halves of the
> 64-bit-wide
> > registers; *and* FreeScale says restrict it to
> libraries and device
> > drivers because SPE will go away in future chips.
>
> Wow. That is obnoxious.
>
> N
|