|
From: Steve B. <ba...@ac...> - 2012-09-20 17:27:52
|
Hi,
I am trying to cross compile valgrind to run on a 16-/32-bit RISC
ARM920T CPU core target running Linux with a 2.6.28.10 kernel. From the
ARM documentation, it looks like the architecture is ARMv4T, but output
of uname -a command shows armv4tl (see below).
*Could someone please tell me if that is possible for valgrind to run on
an ARM920T with the current valgrind releases? *
I have tried valgrind releases 3.8.0 and 3.8.1. I am cross compiling on
a x86 machine running Fedora Core 12 Linux. I've got valgrind to compile
but when I run it on the ARM920T I get illegal instruction (with
./configure --host=armv7-unknown-linux )
Another attempt (with -mcpu=cortex-a8 -mtune=arm920t ) I get
Segmentation fault output from strace as below:
#strace ./memcheck-arm-linux
execve("./memcheck-arm-linux", ["./memcheck-arm-linux"], [/* 12 vars
*/]) = 0
open("/proc/self/maps", O_RDONLY) = 941954700
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
#
If I try to compile with -mcpu=arm920t, I get errors from assembler
about unsupported mov and other instructions.
It looks like the configure script expects some environment variables to
be set beforehand for cross tools such as C compiler, assembler, linker,
lib archive, etc. Not positive I set those correctly, couldn't find doc
anywhere on that. If somebody has list of those environment variables
and what they are for that would be great too.
Other info from output of the following commands:
target# cat /proc/cpuinfo
Processor : ARM920T rev 0 (v4l)
BogoMIPS : 266.24
Features : swp half
CPU implementer : 0x41
CPU architecture: 4T
CPU variant : 0x1
CPU part : 0x920
CPU revision : 0
Hardware : ConnectCore 9M 2443 on a JSCC9M2443 Devboard
Revision : 0000
Serial : 0000000000000000
target# uname -a
Linux cc9m2443js 2.6.28.10 #35 Thu Sep 6 14:19:14 EDT 2012 armv4tl GNU/Linux
If valgrind not possible, if anyone knows of any other
analysis/profiling tools that will work on the ARM920T that info would
be greatly appreciated too.
Thanks in advance,
Steve
|
|
From: Baurzhan I. <ib...@ra...> - 2012-09-20 23:43:16
|
On Thu, Sep 20, 2012 at 01:27:44PM -0400, Steve Bachor wrote: > *Could someone please tell me if that is possible for valgrind to > run on an ARM920T with the current valgrind releases? * IMU, no. > (with ./configure --host=armv7-unknown-linux ) > Another attempt (with -mcpu=cortex-a8 -mtune=arm920t ) > If I try to compile with -mcpu=arm920t, I get errors from assembler IMU, this won't work. > If valgrind not possible, if anyone knows of any other > analysis/profiling tools that will work on the ARM920T that info > would be greatly appreciated too. AFAIK, not in a single package. Which problem are you trying to solve? Depending on your needs, ElectricFence, gcc mudflap / stack protection, multitude of malloc debug libraries, libstdc++ / glib container debugging options, cppcheck, hardware watchpoints could help. With kind regards, Baurzhan. |
|
From: Steve B. <ba...@ac...> - 2012-09-21 15:43:30
|
On 9/20/2012 7:27 PM, Baurzhan Ismagulov wrote: > On Thu, Sep 20, 2012 at 01:27:44PM -0400, Steve Bachor wrote: >> *Could someone please tell me if that is possible for valgrind to >> run on an ARM920T with the current valgrind releases? * > IMU, no. > > >> (with ./configure --host=armv7-unknown-linux ) >> Another attempt (with -mcpu=cortex-a8 -mtune=arm920t ) >> If I try to compile with -mcpu=arm920t, I get errors from assembler > IMU, this won't work. > > >> If valgrind not possible, if anyone knows of any other >> analysis/profiling tools that will work on the ARM920T that info >> would be greatly appreciated too. > AFAIK, not in a single package. Which problem are you trying to solve? Nothing really specific, general performance issues and programming errors. I have one main program that fires off a bunch of threads. Produce a call diagram over time, showing number of calls to functions. Specific problems related to use of threads (pthread_create). Profiling over time, percentage of processor use for all threads; determine if threads are improperly using a high percentage of processor; other threaded programming errors, etc. I hoped to use Valgrind's Helgrind and DRD for some of these. > Depending on your needs, ElectricFence, gcc mudflap / stack protection, > multitude of malloc debug libraries, libstdc++ / glib container > debugging options, cppcheck, hardware watchpoints could help. Thank you, I will check into these tools. > > > With kind regards, > Baurzhan. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Baurzhan I. <ib...@ra...> - 2012-09-21 15:54:44
|
On Fri, Sep 21, 2012 at 11:13:36AM -0400, Steve Bachor wrote: > > Which problem are you trying to solve? ... > Produce a call diagram over time gcc -finstrument-functions > showing number of calls to functions gprof > Profiling over time, percentage of processor use for all threads; > determine if threads are improperly using a high percentage of > processor Not sure, maybe gprof? With kind regards, Baurzhan. |
|
From: Steve B. <ba...@ac...> - 2012-09-23 01:20:19
|
Hi, How about anyone else, ideally a developer, please confirm the following statement is true so I know not to pursue further...... Current or any other releases of valgrind will not run on a 16-/32-bit RISC ARM920T CPU core target. From the ARM documentation, it looks like the architecture is ARMv4T, but output of uname -a command shows it to be armv4tl. Thank you, Steve |
|
From: John R. <jr...@bi...> - 2012-09-23 04:00:18
|
> Current or any other releases of valgrind will not run on a 16-/32-bit > RISC ARM920T CPU core target. From the ARM documentation, it looks like > the architecture is ARMv4T, but output of uname -a command shows it to > be armv4tl. Within the past year I have supplied patches to valgrind-3.7.0 to make memcheck for non-threaded programs run on armv5[t]. This was contentious, and the patches were not accepted into the official source code repository. armv5 has poor hardware support for the atomic update instructions which are necessary to support threading. The patches could be updated to make armv5 work for non-threaded memcheck based on valgrind-3.8.0, but I have purchased an armv7 machine, so I'm no longer highly motivated. armv4 is too ancient, and is not worth fighting for. The lack of the 'bx' instruction is particularly obnoxious. Perhaps armv4t (which has 'bx') might be worth it, but I'm not willing to work on it. Find a way to use almost any current-generation armv7-based tablet computer as a debugging device. They are available at retail for a price of about 1/2 day of an engineer's salary+benefits. Write software stubs for the device-specific hardware of your real device, then link them in and run the main program under memcheck. -- |
|
From: Steve B. <ba...@ac...> - 2012-09-24 15:28:32
|
John, I just wanted to confirm ARM920T not supported for sure. I can now move on to looking for other tools that will run on this processor and/or ending or taking a different approach to my project. I can't really test my app on a v7 board, too many devices to emulate and short time limit on project. Thanks for your response and we in the user community appreciate tools like this for the processors that they do support and those who created them. On 9/23/2012 12:01 AM, John Reiser wrote: >> Current or any other releases of valgrind will not run on a 16-/32-bit >> RISC ARM920T CPU core target. From the ARM documentation, it looks like >> the architecture is ARMv4T, but output of uname -a command shows it to >> be armv4tl. > Within the past year I have supplied patches to valgrind-3.7.0 to make > memcheck for non-threaded programs run on armv5[t]. This was contentious, > and the patches were not accepted into the official source code repository. > armv5 has poor hardware support for the atomic update instructions which > are necessary to support threading. The patches could be updated to make > armv5 work for non-threaded memcheck based on valgrind-3.8.0, > but I have purchased an armv7 machine, so I'm no longer highly motivated. > > armv4 is too ancient, and is not worth fighting for. > The lack of the 'bx' instruction is particularly obnoxious. > Perhaps armv4t (which has 'bx') might be worth it, > but I'm not willing to work on it. > > Find a way to use almost any current-generation armv7-based tablet computer > as a debugging device. They are available at retail for a price of about > 1/2 day of an engineer's salary+benefits. Write software stubs for the > device-specific hardware of your real device, then link them in and run > the main program under memcheck. > |
|
From: Baurzhan I. <ib...@ra...> - 2012-09-24 19:56:49
|
On Sat, Sep 22, 2012 at 09:01:14PM -0700, John Reiser wrote:
> Within the past year I have supplied patches to valgrind-3.7.0 to make
> memcheck for non-threaded programs run on armv5[t]. This was contentious,
> and the patches were not accepted into the official source code repository.
Which is a pity. There is a large installed base of armv5 systems that
desperately need valgrind. I could find some mails in the valgrind-devel
archives that boil down to 1. armv5 support is not perfect, and 2. it
would be costly to make it perfect. Which is also a pity, because 1.
it's ok to have some pieces working better than others -- and what we
have is far better than nothing, 2. if there is no committed baseline,
there will be no improvements ("release early, release often"). Provide
code -- accept patches -- let the community, if any, support that part.
I personally would welcome if the decision would be reviewed.
> Find a way to use almost any current-generation armv7-based tablet computer
> as a debugging device.
As the OP also wrote, it's the periphery that makes this infeasible. If
it were, one could get fairly good results with valgrind on i386
instead.
With kind regards,
Baurzhan.
|
|
From: Gnanasekar <gna...@gm...> - 2012-09-25 16:40:51
|
Even I wanted to run Valgrind badly on my armv5t. I tried few patches but somehow could not get it up & running. And I am not very good at assembly either to make those changes & run it on armv5. So I had to settle with some other tool which is not as good as Valgrind is.
On 25-Sep-2012, at 1:26 AM, Baurzhan Ismagulov <ib...@ra...> wrote:
> On Sat, Sep 22, 2012 at 09:01:14PM -0700, John Reiser wrote:
>> Within the past year I have supplied patches to valgrind-3.7.0 to make
>> memcheck for non-threaded programs run on armv5[t]. This was contentious,
>> and the patches were not accepted into the official source code repository.
>
> Which is a pity. There is a large installed base of armv5 systems that
> desperately need valgrind. I could find some mails in the valgrind-devel
> archives that boil down to 1. armv5 support is not perfect, and 2. it
> would be costly to make it perfect. Which is also a pity, because 1.
> it's ok to have some pieces working better than others -- and what we
> have is far better than nothing, 2. if there is no committed baseline,
> there will be no improvements ("release early, release often"). Provide
> code -- accept patches -- let the community, if any, support that part.
> I personally would welcome if the decision would be reviewed.
>
>
>> Find a way to use almost any current-generation armv7-based tablet computer
>> as a debugging device.
>
> As the OP also wrote, it's the periphery that makes this infeasible. If
> it were, one could get fairly good results with valgrind on i386
> instead.
>
>
> With kind regards,
> Baurzhan.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|