在 7/27/2016 9:08 PM, Arnaldo Carvalho de Melo 写道:
Em Wed, Jul 27, 2016 at 06:49:48PM +0800, Songshan Gong escreveu:
在 7/27/2016 4:29 AM, Arnaldo Carvalho de Melo 写道:
Em Tue, Jul 26, 2016 at 10:14:18PM +0200, Christian Borntraeger escreveu:
On 07/26/2016 09:50 PM, Arnaldo Carvalho de Melo
uct machine *machine, u64 start,
const char *filename);
+int arch__fix_module_text_start(u64 *start, const char *name);
int __machine__load_kallsyms(struct machine *machine, const char *filename,
enum map_type type, bool no_kcore, symbol_filter_t
filter);
--
2.3.0
--
SongShan Gong
le_text_start(u64 *start, const char *name);
int __machine__load_kallsyms(struct machine *machine, const char *filename,
enum map_type type, bool no_kcore, symbol_filter_t
filter);
--
2.3.0
--
SongShan Gong
f/util/machine.h
@@ -216,6 +216,7 @@ struct symbol *machine__find_kernel_function_by_name(struct
machine *machine,
struct map *machine__findnew_module_map(struct machine *machine, u64 start,
const char *filename);
+int arch__fix_module_text_start(u64 *start, const char *name);
64 start,
const char *filename);
+int arch__fix_module_text_start(u64 *start, const char *name);
int __machine__load_kallsyms(struct machine *machine, const char *filename,
enum map_type type, bool no_kcore, symbol_filter_t
filter);
--
SongShan Gong
refers 'A symbol with non-zero length' and this condition
is judged before 'prefer a global symbol';
I have a idea to fix this problem, but may be inappropriate:
Could we move the judge of symbol size to the bottom of the judge
whether a symbol is global?
Anyone else have good idea?
--
SongShan Gong
I try to fix the failure of testcase 'test__vmlinux_matches_kallsyms',
and meet a kind of failure because of duplicate symbols.
For example,two functions:
kretprobe_trampoline_holder and kretprobe_trampoline
(1)They all start from the same addr,0x011b180;
(2)kretprobe_trampoline_holder is STB_
在 7/19/2016 9:50 AM, Songshan Gong 写道:
在 7/19/2016 9:37 AM, Songshan Gong 写道:
在 7/18/2016 10:07 PM, Jiri Olsa 写道:
On Fri, Jul 15, 2016 at 06:15:11PM +0800, Song Shan Gong wrote:
At preset, when creating module's map, perf gets 'start' address by
parsing
'/proc/modul
在 7/19/2016 9:37 AM, Songshan Gong 写道:
在 7/18/2016 10:07 PM, Jiri Olsa 写道:
On Fri, Jul 15, 2016 at 06:15:11PM +0800, Song Shan Gong wrote:
At preset, when creating module's map, perf gets 'start' address by
parsing
'/proc/modules', but it's module base addre
ion_by_name(struct
machine *machine,
struct map *machine__findnew_module_map(struct machine *machine, u64 start,
const char *filename);
+int arch__fix_module_text_start(u64 *start, const char *name);
int __machine__load_kallsyms(struct machine *machine, const char *filename,
enum map_type type, bool no_kcore, symbol_filter_t
filter);
--
SongShan Gong
在 7/13/2016 5:07 PM, Jiri Olsa 写道:
On Wed, Jul 13, 2016 at 02:39:13PM +0800, Songshan Gong wrote:
在 7/11/2016 8:01 PM, Jiri Olsa 写道:
On Mon, Jul 11, 2016 at 07:06:14PM +0800, Songshan Gong wrote:
SNIP
we have following functions in tools/lib/api/fs to read
single number from file
在 7/11/2016 8:01 PM, Jiri Olsa 写道:
On Mon, Jul 11, 2016 at 07:06:14PM +0800, Songshan Gong wrote:
SNIP
we have following functions in tools/lib/api/fs to read
single number from file, which I assume you do above:
int sysfs__read_int(const char *entry, int *value);
int sysfs__read_ull
I send this email to test the connection to linux-kernel maillist. Just
ignore.
在 7/11/2016 4:11 PM, Songshan Gong 写道:
在 7/8/2016 11:18 PM, Jiri Olsa 写道:
On Thu, Jul 07, 2016 at 09:49:36AM +0800, Song Shan Gong wrote:
At preset, when creating module's map, perf gets 'start
.
Each value in /sys/module/[module name]/sections/.text is a string like
"0x03ff8130078\n".
But the core function 'strtoull(line, NULL, 10)' in sysfs__read_ull is
based on decimal.
Maybe you can introduce a new argument indicating the value is based on
hex or decimal, or binary?
thanks,
jirka
--
SongShan Gong
tion, when loading by parsing /proc/kallsyms, if the kernel
map start value is a non-zero value getting from '_stext', because
'_text' is zero, it will not be included in kernel map; but for vmlinux,
it always add '_text' to kernel map whether '_text' is zero or not. So
if '_text' is zero, whether adding '_text' to kernel map, it's
non-consistent for loading by /proc/kallsyms and vmlinux.
I'll try to fix this bug later.
Thanks for your comments.
I'll send few coments shortly
thanks,
jirka
--
SongShan Gong
ruct machine *machine, u64 start,
const char *filename);
+int arch__fix_module_baseaddr(struct machine *machine, u64 *start,
+ const char *name);
int __machine__load_kallsyms(struct machine *machine, const char *filename,
enum map_type type, bool no_kcore, symbol_filter_t
filter);
--
SongShan Gong
16 matches
Mail list logo