Closed GoogleCodeExporter closed 9 years ago
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
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
Original comment by csilv...@gmail.com
on 11 Mar 2009 at 9:24
Issue 164 has been merged into this issue.
Original comment by csilv...@gmail.com
on 22 Aug 2009 at 4:07
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
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
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:
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
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
Thanks,
I will test it and report back.
Ravi
Original comment by r...@codeaurora.org
on 6 Jan 2011 at 4:58
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
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
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
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
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
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
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
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
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
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
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
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
@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
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
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
Original issue reported on code.google.com by
andrew...@gmail.com
on 25 Feb 2009 at 1:02