Bug 336768

(In reply to croh92 from comment #0)

What board are you running this on?
Can you do 'cat /proc/cpuinfo' and paste the output here?

I suspect this is one of the old BRCM boards, and this might be
their proprietary encoding of the RDHWR instruction.

  : BCM97xxx Settop Platform
build target            : 
processor               : 0
cpu model               : BMIPS4380 V4.4  FPU V0.1
cpu MHz                 : 402.43
BogoMIPS                : 402.43    ( udelay_val : 201216  HZ = 1000 )
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        : mips16
VCED exceptions         : not available
VCEI exceptions         : not available
RAC setting             : I/D-RAC enabled
unaligned access        : 0
rdhwr/brdhwr traps      : 0 / 0

(In reply to Petar Jovanovic from comment #1)
> (In reply to croh92 from comment #0)
> 
> What board are you running this on?
> Can you do 'cat /proc/cpuinfo' and paste the output here?
> 
> I suspect this is one of the old BRCM boards, and this might be
> their proprietary encoding of the RDHWR instruction.

Created attachment 87890 [details]
BMIPS patch

Can you try this patch and let me know if the behaviour is different?

Hello,

After modifying m_machine.c and running the valgrind executable, I get an error that says: "Illegal Instruction" when I run

./valgrind ls -l

Thanks,
CHris
(In reply to Petar Jovanovic from comment #3)
> Created attachment 87890 [details]
> BMIPS patch
> 
> Can you try this patch and let me know if the behaviour is different?

Created attachment 87901 [details]
attachment-4568-0.html

Hello,

I just sent you a reply on the valgrind bug report thread,

Thanks


On Tue, Jul 22, 2014 at 8:06 PM, Petar Jovanovic <mips32r2@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=336768
>
> --- Comment #3 from Petar Jovanovic <mips32r2@gmail.com> ---
> Created attachment 87890 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=87890&action=edit
> BMIPS patch
>
> Can you try this patch and let me know if the behaviour is different?
>
> --
> You are receiving this mail because:
> You reported the bug.
>

(In reply to croh92 from comment #5)
> Created attachment 87901 [details]
> attachment-4568-0.html
> 
> Hello,
> 
> I just sent you a reply on the valgrind bug report thread,
> 
> Thanks
> 
> 
> On Tue, Jul 22, 2014 at 8:06 PM, Petar Jovanovic <mips32r2@gmail.com> wrote:
> 
> > https://bugs.kde.org/show_bug.cgi?id=336768
> >
> > --- Comment #3 from Petar Jovanovic <mips32r2@gmail.com> ---
> > Created attachment 87890 [details]
> >   --> https://bugs.kde.org/attachment.cgi?id=87890&action=edit
> > BMIPS patch
> >
> > Can you try this patch and let me know if the behaviour is different?
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.
> >

Can you configure Valgrind for "mips32" instead of "mips32r2"?
Your Broadcom board is MIPS32R1 compliant.

Hello,

Here are the steps I took:

./autogen.sh
./configure --host=mipsel-linux-gnu CFLAGS="mips32" --with-pagesize=4
make clean
make
make install

And still no luck. I am still getting an error that says "Illegal Instruction".

Any other ideas?

Thanks,
Chris

(In reply to Petar Jovanovic from comment #6)
> (In reply to croh92 from comment #5)
> > Created attachment 87901 [details]
> > attachment-4568-0.html
> > 
> > Hello,
> > 
> > I just sent you a reply on the valgrind bug report thread,
> > 
> > Thanks
> > 
> > 
> > On Tue, Jul 22, 2014 at 8:06 PM, Petar Jovanovic <mips32r2@gmail.com> wrote:
> > 
> > > https://bugs.kde.org/show_bug.cgi?id=336768
> > >
> > > --- Comment #3 from Petar Jovanovic <mips32r2@gmail.com> ---
> > > Created attachment 87890 [details]
> > >   --> https://bugs.kde.org/attachment.cgi?id=87890&action=edit
> > > BMIPS patch
> > >
> > > Can you try this patch and let me know if the behaviour is different?
> > >
> > > --
> > > You are receiving this mail because:
> > > You reported the bug.
> > >
> 
> Can you configure Valgrind for "mips32" instead of "mips32r2"?
> Your Broadcom board is MIPS32R1 compliant.

(In reply to croh92 from comment #7)
> Hello,
> 
> Here are the steps I took:
> 
> ./autogen.sh
> ./configure --host=mipsel-linux-gnu CFLAGS="mips32" --with-pagesize=4

Have you set CFLAGS="-mips32" or CFLAGS="mips32"?

I have tried CFLAGS="-mips32"
(In reply to Petar Jovanovic from comment #8)
> (In reply to croh92 from comment #7)
> > Hello,
> > 
> > Here are the steps I took:
> > 
> > ./autogen.sh
> > ./configure --host=mipsel-linux-gnu CFLAGS="mips32" --with-pagesize=4
> 
> Have you set CFLAGS="-mips32" or CFLAGS="mips32"?

(In reply to croh92 from comment #9)
Can you do some debugging on your side?
Can you do 'file bin/*' in your install directory?
Can you make sure you have built mips32r1 binaries?

For each of the files in my install directory, it says "ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), not stripped".

(In reply to Petar Jovanovic from comment #10)
> (In reply to croh92 from comment #9)
> Can you do some debugging on your side?
> Can you do 'file bin/*' in your install directory?
> Can you make sure you have built mips32r1 binaries?

(In reply to croh92 from comment #11)
> For each of the files in my install directory, it says "ELF 32-bit LSB
> executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared
> libs), not stripped".

Can you post the whole output when you run Valgrind?
Does Valgrind work if you do *not* pass any executable to it?
I presume that 'ls' is working correctly as a standalone program/command?

Here is the output when I run "./valgrind ls -l"
./valgrind ls -l
==114== Memcheck, a memory error detector
==114== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==114== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==114== Command: ls -l
==114==
==114== Conditional jump or move depends on uninitialised value(s)
==114==    at 0x400632C: ??? (in /lib/ld-uClibc-0.9.29.so)
==114==    by 0x400101C: _start (in /lib/ld-uClibc-0.9.29.so)
==114==
Stack about to get dumped!!!!!Call Trace:
[<8000ed94>] dump_stack+0x20/0x50
[<8000aef8>] do_signal+0x3c4/0x424
[<80005c70>] work_notifysig+0xc/0x14

Skipped the if statement...:(:(vex mips->IR: unhandled instruction bytes: 0x3B 0xE8 0x3 0xEC
==114== valgrind: Unrecognised instruction at address 0x4859648.
==114==    at 0x4859648: _stdio_init (in /lib/libuClibc-0.9.29.so)
==114==    by 0x40060E0: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.29.so)
==114== Your program just tried to execute an instruction that Valgrind
==114== did not recognise.  There are two possible reasons for this.
==114== 1. Your program has a bug and erroneously jumped to a non-code
==114==    location.  If you are running Memcheck and you just saw a
==114==    warning about a bad jump, it's probably your program's fault.
==114== 2. The instruction is legitimate but Valgrind doesn't handle it,
==114==    i.e. it's Valgrind's fault.  If you think this is the case or
==114==    you are not sure, please let us know and we'll try to fix it.
==114== Either way, Valgrind will now raise a SIGILL signal which will
==114== probably kill your program.
==114==
==114== Process terminating with default action of signal 4 (SIGILL)
==114==  Illegal opcode at address 0x4859648
==114==    at 0x4859648: _stdio_init (in /lib/libuClibc-0.9.29.so)
==114==    by 0x40060E0: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.29.so)
ls: can't resolve symbol '__libc_freeres' in lib '/usr/local/lib/valgrind//vgpreload_core-mips32-linux.so'.
==114==
==114== HEAP SUMMARY:
==114==     in use at exit: 0 bytes in 0 blocks
==114==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==114==
==114== All heap blocks were freed -- no leaks are possible
==114==
==114== For counts of detected and suppressed errors, rerun with: -v
==114== Use --track-origins=yes to see where uninitialised values come from
==114== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Illegal instruction

When I run "ls" without valgrind, it works correctly and lists the files in my current directory.
(In reply to Petar Jovanovic from comment #12)
> (In reply to croh92 from comment #11)
> > For each of the files in my install directory, it says "ELF 32-bit LSB
> > executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared
> > libs), not stripped".
> 
> Can you post the whole output when you run Valgrind?
> Does Valgrind work if you do *not* pass any executable to it?
> I presume that 'ls' is working correctly as a standalone program/command?

(In reply to croh92 from comment #13)
> Here is the output when I run "./valgrind ls -l"

I am still under impression that you have misconfigured Valgrind or missed to apply the patch.
Can you enable remote ssh access to your board and the system?

I'm experience the same issue :
# ./bin/valgrind ls
==120== Memcheck, a memory error detector
==120== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==120== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==120== Command: ls
==120== 
vex mips->IR: unhandled instruction bytes: 0x3B 0xE8 0x3 0xEC
==120== valgrind: Unrecognised instruction at address 0x485b648.
==120==    at 0x485B648: _stdio_init (in /lib/libuClibc-0.9.29.so)
==120==    by 0x40060E0: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.29.so)
==120== Your program just tried to execute an instruction that Valgrind
==120== did not recognise.  There are two possible reasons for this.
==120== 1. Your program has a bug and erroneously jumped to a non-code
==120==    location.  If you are running Memcheck and you just saw a
==120==    warning about a bad jump, it's probably your program's fault.
==120== 2. The instruction is legitimate but Valgrind doesn't handle it,
==120==    i.e. it's Valgrind's fault.  If you think this is the case or
==120==    you are not sure, please let us know and we'll try to fix it.
==120== Either way, Valgrind will now raise a SIGILL signal which will
==120== probably kill your program.
==120== 
==120== Process terminating with default action of signal 4 (SIGILL)
==120==  Illegal opcode at address 0x485B648
==120==    at 0x485B648: _stdio_init (in /lib/libuClibc-0.9.29.so)
==120==    by 0x40060E0: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.29.so)
==120== 
==120== HEAP SUMMARY:
==120==     in use at exit: 0 bytes in 0 blocks
==120==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==120== 
==120== All heap blocks were freed -- no leaks are possible
==120== 
==120== For counts of detected and suppressed errors, rerun with: -v
==120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

My config for compiling:
./configure --prefix=/home/my_name/valgrind/export_3.10.1 --host=mipsel-linux-gnu CFLAGS=" -mips32r2" CPPFLAGS="-D__UCLIBC__" CC=/opt/toolchains/gcc-4.2.0/bin/mipsel-uclibc-gcc CXX=/opt/toolchains/gcc-4.2.0/bin/mipsel-uclibc-g++

Are you using the patch?
What system are you running it on?
Can you do 'cat /proc/cpuinfo' and paste the output here?
Please provide as much details as possible.

But it seems that your patch fix the problem! Thanks!

Petar Jovanovic, thank you for patch.

for information:

# uname -a
Linux (none) 2.6.18-7.4 #11 Fri Jun 27 03:06:16 KST 2014 97459b0 unknown
# 
# cat /proc/cpuinfo 
system type             : BCM97xxx Settop Platform
build target            : OCAP_STB
processor               : 0
cpu model               : BMIPS4380 V4.4  FPU V0.1
cpu MHz                 : 402.43
BogoMIPS                : 402.43    ( udelay_val : 201216  HZ = 1000 )
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        : mips16
VCED exceptions         : not available
VCEI exceptions         : not available
RAC setting             : I/D-RAC enabled
unaligned access        : 280
rdhwr/brdhwr traps      : 0 / 0

I believe we can close this issue now.

This issue should be closed.

I was not able to find what is the status of this bug.
Was the patch integrated? If yes, then what is its SVN revision?
If not, then why not?

(In reply to Ivo Raisr from comment #22)
> I was not able to find what is the status of this bug.

Not sure either, but it seems that no one is complaining on this matter
anymore. It has been more than 2 years since the last response, and the
last comment was "it seems that your patch fix the problem! Thanks!"

So, I would close this issue if there is no one to claim a problem.

I believe the issue was fixed by people applying locally the patch from the comment #3.
This has not been upstreamed as it seems applicable only for the old BRCM systems, when their kernel did not use to publish full company name in the "cpu model" section. The problem itself is also, I believe, related to a very weird proprietary encoding of RDHWR instruction that is not in use on Broadcom systems anymore.