failed to cross-compile for ARM

[GoogleCodeExporter]

Hello,
I am trying to cross-compile google-perftools-0.8 for ARM and I ran into
some problems. First of all, ca someone tell me if this tools can be
cross-compiled for ARM?? I think not, cause the "sigcontext" structure
located in "<asm/sigcontext.h>" is very different for ARM than for X86. Is
there any other version of google-perftools that can be cross-compiled for
ARM??

Thanks

Original issue reported on code.google.com by andrew...@gmail.com on 25 Feb 2009 at 1:02

[GoogleCodeExporter]

perftools will only work on i386, x86_64, and ppc at the moment.  If you'd like 
to
submit a patch to support another CPU architecture, that would be great!  Most 
of the
work should be in the stacktrace code -- a new stacktrace_arm-inl.h -- and in 
the
spinlock code.  I don't know how much work it would be to do that for ARM.

Original comment by csilv...@gmail.com on 25 Feb 2009 at 7:59

• Added labels: Priority-Low, Type-Enhancement

[GoogleCodeExporter]

Ok, thank you for your answer. If I'll ever get the time to do that I will post 
it
here for sure.

Regards

Original comment by andrew...@gmail.com on 26 Feb 2009 at 7:48

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 11 Mar 2009 at 9:24

• Added labels: Type-Porting
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Issue 164 has been merged into this issue.

Original comment by csilv...@gmail.com on 22 Aug 2009 at 4:07

[GoogleCodeExporter]

Hi, 
I have an ARM port running, though I am having trouble with the stack trace 
part of it. It would be nice to get feedback and ideas for the stacktracer part 
of it.
How do I upload the patch and get a review going so that ARM is available as a 
supported arch ?

Regards,
Ravi 

Original comment by r...@codeaurora.org on 9 Dec 2010 at 8:30

[GoogleCodeExporter]

Great!  You can submit patches here: just attach them to a comment.  You'll 
also need to sign the CLA at
   http://code.google.com/legal/individual-cla-v1.0.html

Original comment by csilv...@gmail.com on 9 Dec 2010 at 9:48

[GoogleCodeExporter]

Hi,
I am attaching a patch which enables ARM support. The code is still rough 
around the edges and I hope that the review will help me shape it up. 

The stack tracing part of it not working, which, I think is causing 9 out of 41 
tests to fail. 

Failing Tests:
stacktrace_unittest
sampling_test.sh
heap-profiler_unittest.sh
heap-checker_unittest.sh
heap-checker-death_unittest.sh
sampling_debug_test.sh
heap-profiler_debug_unittest.sh
heap-checker_debug_unittest.sh
profiler_unittest.sh

I configure with the --enable-frame-pointers flag passed. 

Please comment ... 

Thanks,
Ravi 

Original comment by r...@codeaurora.org on 4 Jan 2011 at 4:46

Attachments:

• patch_tcmalloc_approved.patch

[GoogleCodeExporter]

Great, thanks for the patch!  It looks like you may need the corporate CLA,
rather than the individual CLA; that one is at
   http://code.google.com/legal/corporate-cla-v1.0.html
Let me know when you've signed whichever one you (and your company) decide is 
appropriate.

I'm not surprised stacktrace_generic.h doesn't work with arm; we'll need 
something more arm-specific, if it's possible.  Or maybe libunwind works with 
arm, at least with --enable-frame-pointers?  I don't know if you've tried that.

It's easy to get this patch in a little bit at a time -- I will try to recruit 
some local experts here to help with the arm reviews -- so we can start on that 
once the CLA is done.

Original comment by csilv...@gmail.com on 5 Jan 2011 at 8:45

[GoogleCodeExporter]

I'm embarrassed that I didn't realize this before, but we've already 
incorporated a lot of the arm functionality into perftools (written by someone 
internal at Google).  Take a look at the svn-root of this project:
   http://code.google.com/p/google-perftools/source/browse/#svn%2Ftrunk%2Fsrc

According to the author, this incorporates all of your patch except for the 
cycle-timer stuff (which was done in a slightly different way).  Do you want to 
try the svn-root perftools and see how it works for you?  Apparently the 
stack-trace wasn't working for him either, so there may be opportunities for 
improvement there.

Original comment by csilv...@gmail.com on 5 Jan 2011 at 10:49

[GoogleCodeExporter]

Thanks, 
I will test it and report back. 

Ravi

Original comment by r...@codeaurora.org on 6 Jan 2011 at 4:58

[GoogleCodeExporter]

The tip of SVN is not working for me.. I think some minor changes will get it 
to work.

1. The code only checks for __ARM_ARCH_5T__. I am using a compiler which by 
defaults defines __ARM_ARCH_6__ and others (depending on the switches of 
course). 
There are so many such mutually exclusive ARM_ARCH_* defines that it makes the 
code brittle. The best way imho is that autoconfigure should parse the output 
of what the compiler defined (using the appropriate --march= value) and set the 
ARM_ARCH_VERSION macro. This will allow us to have clean #if ARM_ARCH_VERSION > 
6 kind of constructs.

I found the following page helpful 
https://wiki.edubuntu.org/ARM/Thumb2PortingHowto.

2. The syscall interface is broken, as far as i can tell (correct me if i am 
wrong please). I think I had solved this problem in my patch attached above.

Symptom is error below 
In file included from src/base/spinlock_internal.cc:48:
./src/base/spinlock_linux-inl.h: In constructor 
â<unnamed>::InitModule::InitModule()â:
./src/base/spinlock_linux-inl.h:53: error: âsys_futexâ was not declared in 
this scope
./src/base/spinlock_linux-inl.h: In function âvoid 
base::internal::SpinLockDelay(volatile Atomic32*, int32, int)â:
./src/base/spinlock_linux-inl.h:69: error: âerrnoâ was not declared in this 
scope
./src/base/spinlock_linux-inl.h:81: error: âsys_futexâ was not declared in 
this scope
./src/base/spinlock_linux-inl.h: In function âvoid 
base::internal::SpinLockWake(volatile Atomic32*, bool)â:
./src/base/spinlock_linux-inl.h:92: error: âsys_futexâ was not declared in 
this scope
make: *** [spinlock_internal.lo] Error 1

3. I added in src/base/atomicops-internals-arm-gcc.h a #include <stdlib.h> for 
abort()

I am still sorting through some compilation issues more issues and report back 
when its done. 

Original comment by r...@codeaurora.org on 7 Jan 2011 at 11:00

[GoogleCodeExporter]

Thanks for the pointers -- I admit I don't know anything about porting for ARM. 
 My impression was all the ARM architectures were so different that saying 
"version >= 5" is pretty meaningless; you have to separately enumerate all 
possible arm versions you want to support.  If that's not true, I'm glad to get 
the ARM version via autoconf.

We are compiling the existing code for ARM, I think; I'll check with some local 
users here to see if they can understand the compile errors.

Original comment by csilv...@gmail.com on 7 Jan 2011 at 11:10

[GoogleCodeExporter]

I do agree that a more flexible ARM identification should be performed. As for 
the syscalls, I'll check the syscall patch on my system. It may take couple of 
days, as we are transitioning to a new platform.

Original comment by sa...@google.com on 7 Jan 2011 at 11:52

[GoogleCodeExporter]

Thanks all for the responses. 

The arm archs are definetly different but all we care about is which 
instruction set is supported and for our purposes the arch version is 
sufficient. 

I am curious if anyone cross-compiles for ARM. I usually just build it on 
target. 
After my cursory look inside configure.ac , I dont think it is supported ? (I 
think because only AC_CANONICAL_HOST and no AC_CANONICAL_SYSTEM was present, so 
no --target... AFAIR)

Original comment by r...@codeaurora.org on 10 Jan 2011 at 4:42

[GoogleCodeExporter]

Just to give an update: I've brought up my test system and trying out your 
patch. I haven't been able to verify it in our environment yet, but one thing 
for sure - the patch will not be arm v5 compatible as it uses assembly 
instructions from the newer arch.

Original comment by sa...@google.com on 20 Jan 2011 at 5:05

[GoogleCodeExporter]

yes you are absolutely right. LDREX/STREX are v6+ instructions.. the gcc 
intrinsics could be used (as already there) or use SWP based implementation for 
the locks. 
Is there any advantage of implementing atomic-ops v/s using gcc intrinsics of 
the same ?
Thanks for testing it out. 
Sorry I did not guard the assembly instructions properly (__ARM_ARCH_6__ or 
something like that). This was the part of the code where the autoconfigure 
trick i mentioned earlier would come in handy.. 

Original comment by ravishan...@gmail.com on 20 Jan 2011 at 8:12

[GoogleCodeExporter]

One more update... I am debugging an issue that may be connected to the 
atomic-ops, but it manifests itself on both your implementation and the gcc 
intrinsics. I have not identified the issue yet.

Original comment by sa...@google.com on 27 Jan 2011 at 9:34

[GoogleCodeExporter]

I could try and reproduce/debug it as well if you tell me the steps.. 

Original comment by r...@codeaurora.org on 3 Feb 2011 at 7:53

[GoogleCodeExporter]

Finally I found out why I had all these problems - my system doesn't support 
the old sys_futex() interface.
I've fixed that and was able to test your changes. They work.

Original comment by sa...@google.com on 16 Feb 2011 at 7:06

[GoogleCodeExporter]

Great, glad to hear you've figured it out!

I forget exactly where we stand now.  Does this mean I can close the bug?

Original comment by csilv...@gmail.com on 16 Feb 2011 at 8:16

[GoogleCodeExporter]

so.. are we doing the autoconfigure trick to check the arm arch ? Would also 
like to know if the tip will soon support arch > 5

Original comment by ravishan...@gmail.com on 17 Feb 2011 at 7:31

[GoogleCodeExporter]

I don't think we're doing anything with autoconf, just using the hard-coded 
macros that each arm processor writes.

I'm still confused about how all the arches play together, so if you think 
there are further improvements to be made, best might be to just submit a patch 
against svn-root.

Original comment by csilv...@gmail.com on 17 Feb 2011 at 9:50

[GoogleCodeExporter]

@CSilver, what is the deal on this one? does perftools support ARM versions >5?

Original comment by sunnysha...@gmail.com on 22 Jul 2011 at 2:09

[GoogleCodeExporter]

A good question -- I think it does, but can't say for sure because I don't have 
an ARM machine to test on.  Feel free to download the latest perftools release 
and try it out, and report back!

Original comment by csilv...@gmail.com on 22 Jul 2011 at 8:54

[GoogleCodeExporter]

OK, I'm going to assume everything is fixed at this time, and close the bug.  
Feel free to reopen it (or open a new bug), if you see more ARM-specific issues.

Original comment by csilv...@gmail.com on 12 Oct 2011 at 11:09

• Changed state: Fixed