Re: [PATCH] [RFC V1]s390/perf: fix 'start' address of module's map

[Songshan Gong <gongss@linux.vnet.ibm.com>]

在 7/8/2016 11:21 PM, Jiri Olsa 写道:
> On Thu, Jul 07, 2016 at 09:49:36AM +0800, Song Shan Gong wrote:
>
> SNIP
>
>> +	char *line = NULL;
>> +	size_t n;
>> +	char *sep;
>> +
>> +	module_name[len - 1] = '\0';
>> +	module_name += 1;
>> +	snprintf(path, PATH_MAX, "%s/sys/module/%s/sections/.text",
>> +				machine->root_dir, module_name);
>> +	file = fopen(path, "r");
>> +	if (file == NULL)
>> +		return -1;
>> +
>> +	len = getline(&line, &n, file);
>> +	if (len < 0) {
>> +		err = -1;
>> +		goto out;
>> +	}
>> +	line[--len] = '\0'; /* \n */
>> +	sep = strrchr(line, 'x');
>> +	if (sep == NULL) {
>> +		err = -1;
>> +		goto out;
>> +	}
>> +	hex2u64(sep + 1, &text_start);
>
> 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(const char *entry, unsigned long long *value);
>
> please check if you could use some of them,
> we could add some more generic one if needed

It seems infeasible.
Each value in /sys/module/[module name]/sections/.text is a string like 
"0x000003ff8130078\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