Closed Bug 674986 Opened 9 years ago Closed 7 years ago

Build profiler for android devices

Categories

(Core :: General, defect)

Other Branch
ARM
MeeGo
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 831611

People

(Reporter: cjones, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: mobilestartupshrink)

Attachments

(1 file)

jchen got oprofile working for the MSM7230 (G2) on cyanogenmod7: https://wiki.mozilla.org/Mobile/Fennec/Android/Profiling.

cjones has oprofile almost working with a Hummingbird S5PC110 (Nexus S) on top of a userspace with -fno-omit-frame-pointer (i.e. should get callgraphs).

It would be interesting to investigate the perf tool, since that's going to be our most reliable option moving forward.  Looks like some significant build hackery is needed to cross-compile it in the kernel source though.
samples  %        image name               app name                 symbol name
-------------------------------------------------------------------------------
1646      5.6573  libxul.so                libxul.so                pixman_composite_src_0565_0565_asm_neon
  1646     100.000  libxul.so                libxul.so                pixman_composite_src_0565_0565_asm_neon [self]
-------------------------------------------------------------------------------
1408      4.8393  libc.so                  libc.so                  memcpy
  1408     100.000  libc.so                  libc.so                  memcpy [self]
-------------------------------------------------------------------------------
635       2.1825  oprofiled                oprofiled                odb_update_node_with_offset
  635      100.000  oprofiled                oprofiled                odb_update_node_with_offset [self]
-------------------------------------------------------------------------------
  1        25.0000  vmlinux                  vmlinux                  vma_adjust
  1        25.0000  vmlinux                  vmlinux                  split_vma
  2        50.0000  vmlinux                  vmlinux                  __split_vma
482       1.6566  vmlinux                  vmlinux                  ring_buffer_consume
  482      50.0000  vmlinux                  vmlinux                  ring_buffer_consume [self]
  428      44.3983  vmlinux                  vmlinux                  __run_hrtimer
  41        4.2531  vmlinux                  vmlinux                  enqueue_hrtimer
  7         0.7261  vmlinux                  vmlinux                  hrtimer_run_queues
  6         0.6224  vmlinux                  vmlinux                  hrtimer_cancel
-------------------------------------------------------------------------------
373       1.2820  vmlinux                  vmlinux                  __do_softirq
  373      42.0045  vmlinux                  vmlinux                  v6_copy_user_highpage_nonaliasing
  373      42.0045  vmlinux                  vmlinux                  __do_softirq [self]
  49        5.5180  vmlinux                  vmlinux                  s3c_config_cdma_wimax_sleep_gpio
  46        5.1802  vmlinux                  vmlinux                  do_alignment_ldmstm
  36        4.0541  vmlinux                  vmlinux                  thread_group_cputime
-------------------------------------------------------------------------------
329       1.1308  libxul.so                libxul.so                pixman_composite_over_8888_0565_asm_neon
  329      100.000  libxul.so                libxul.so                pixman_composite_over_8888_0565_asm_neon [self]
-------------------------------------------------------------------------------
299       1.0277  vmlinux                  vmlinux                  schedule
  299      49.5033  vmlinux                  vmlinux                  schedule [self]
  280      46.3576  vmlinux                  vmlinux                  l2cap_conn_start
  19        3.1457  vmlinux                  vmlinux                  l2cap_security_cfm
  4         0.6623  vmlinux                  vmlinux                  add_wait_queue_exclusive
-------------------------------------------------------------------------------
286       0.9830  libm.so                  libm.so                  floor
  286      100.000  libm.so                  libm.so                  floor [self]
-------------------------------------------------------------------------------
272       0.9349  anon (tgid:468 range:0x45ba9000-0x45bd9000) app_process              anon (tgid:468 range:0x45ba9000-0x45bd9000)
  272      100.000  anon (tgid:468 range:0x45ba9000-0x45bd9000) app_process              anon (tgid:468 range:0x45ba9000-0x45bd9000) [self]
-------------------------------------------------------------------------------
271       0.9314  libxul.so                libxul.so                _cairo_spline_decompose_into
  271      100.000  libxul.so                libxul.so                _cairo_spline_decompose_into [self]
-------------------------------------------------------------------------------
259       0.8902  libxul.so                libxul.so                nsRect::ScaleToNearestPixels(float, float, int) const
  259      100.000  libxul.so                libxul.so                nsRect::ScaleToNearestPixels(float, float, int) const [self]
Oops, fatfingered enter.  Meant to say,

Here's some oprofile pr0n.  I have the frame pointers I need to get a callgraph, and I'm telling oprofile to collect backtraces, but something is being lost in translation somewhere.

I wonder if we have to force thumb off to get reliable backtraces.  That's OK, but not so great since it will skew results even more.
Whiteboard: mobilestartupshrink
(In reply to comment #2)
> Oops, fatfingered enter.  Meant to say,
> 
> Here's some oprofile pr0n.  I have the frame pointers I need to get a
> callgraph, and I'm telling oprofile to collect backtraces, but something is
> being lost in translation somewhere.
> 
> I wonder if we have to force thumb off to get reliable backtraces.  That's
> OK, but not so great since it will skew results even more.

Yeah, currently oprofile backtrace only supports arm mode frame pointers (using fp register), and not thumb mode frame pointers (using r7 register). It should be trivial to add thumb support.

However, gcc 4.4.3 (NDKr5) generates wrong frame pointers in thumb mode anyways, so oprofile support alone is not enough for thumb support. Basically, in thumb mode, gcc always sets the frame pointer to the stack pointer, which defeats the purpose of having a frame pointer.
(In reply to comment #3)
> (In reply to comment #2)
> > Oops, fatfingered enter.  Meant to say,
> > 
> > Here's some oprofile pr0n.  I have the frame pointers I need to get a
> > callgraph, and I'm telling oprofile to collect backtraces, but something is
> > being lost in translation somewhere.
> > 
> > I wonder if we have to force thumb off to get reliable backtraces.  That's
> > OK, but not so great since it will skew results even more.
> 
> Yeah, currently oprofile backtrace only supports arm mode frame pointers
> (using fp register), and not thumb mode frame pointers (using r7 register).
> It should be trivial to add thumb support.

I built my entire userspace and firefox without thumb support and still didn't get callgraphs.  I think there might be some other bug.  Going to push what I have later today.

"Real" thumb support doesn't sound trivial to me at all, but if you have an implementation in mind more power to you :).  We could fall back on heuristics like if r11 doesn't point at a valid address, try r7 (or vice versa), but that's not strictly correct.
(In reply to comment #4)
> I built my entire userspace and firefox without thumb support

Ah-ha: I checked this assumption by commenting out the thumb options instead of disabling them with build flags, and got a linker error.  So looks like I wasn't turning off thumb after all.
(In reply to comment #4)
> I built my entire userspace and firefox without thumb support and still
> didn't get callgraphs.  I think there might be some other bug.  Going to
> push what I have later today.
> 
> "Real" thumb support doesn't sound trivial to me at all, but if you have an
> implementation in mind more power to you :).  We could fall back on
> heuristics like if r11 doesn't point at a valid address, try r7 (or vice
> versa), but that's not strictly correct.

My way would be to detect thumb mode or arm mode based on cpsr and return addresses, and choose fp or r7 based on the detected mode.

FWIW, here's a patch I wrote based on an even hackier algorithm. It scans the stack and looks for likely return addresses (valid and executable memory region, branch instruction before return address, etc.) It helped me getting the oprofile backtrace in bug 658074.
Rebuilt userspace with thumb commented out, but no luck; still no callgraphs.  Definitely worth investigating.

Jim's patch is giving me results though.  Thanks!  We should probably look into cleaning it up and getting it merged into linux mainline.
Some work pwalton did on an Android profiler: https://github.com/pcwalton/piranha
OS: Android → MeeGo
Version: Trunk → Other Branch
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 831611
You need to log in before you can comment on or make changes to this bug.