lkml.org 
[lkml]   [2018]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectftrace: Proposal for an Alternative RecordMcount framework
Hi Steven,

Current recordmcount framework collects the mcount call-sites by grep'ing
the relocation info in each *.o file right after it is compiled, and then
puts them into the __mcount_loc_start array. This works fine in many
architectures, but as mentioned in this riscv/ftrace patch[1], aggressive
relaxing optimizations corrupt the collected offsets, resulting in panics
due to wrong call-site patching in runtime.

Meanwhile, some architectures, such as RISC-V and the on-going nds32, highly
rely on linker relaxation as a link-time optimization to reduce code size
and improve performance. It would be very undesirable to sacrifice them for
ftrace only. But, why can't we collect the call-sites after all of them
are fixed?

We propose an alternative framework, for architectures that cannot
properly record call-sites because of relaxing. Here is the rough
procedure:

1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2]
2. Form the output as an ELF objecj
3. Link the object to __mcount_loc_start symbol
4. Done

With the similar reason as the patch [3], we should mark _mcount to be
a weak symbol to prevent it from being relaxed later.

We would like to know your opinion and comments on this.
Thanks!

Alan Kao

[1] riscv/ftrace dynamic support [patch v4 1/6]:
https://lkml.org/lkml/2018/2/13/12
[2] This used to not collect some call-sites since their jumps has no
target symbol hint. It becomes possible after the fix in 2.30 release.
See https://github.com/riscv/riscv-binutils-gdb/issues/129 for more
details.
[3] https://lkml.org/lkml/2016/5/14/101

\
 
 \ /
  Last update: 2018-02-27 11:08    [W:0.177 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site