Re: Problems with commit 'kallsyms: add support for relative offsets in kallsyms address table' (in mmotm)

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

> On 24 jan. 2016, at 20:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
> 
> 
>> On 24 jan. 2016, at 19:01, Guenter Roeck <linux@roeck-us.net> wrote:
>> 
>> On 01/24/2016 09:20 AM, Ard Biesheuvel wrote:
>> [ ... ]
>>>>> OK, there's an additional issue in my latest version: the
>>>>> kallsyms_relative_base value itself is not relocated.
>>>>> 
>>>>> If you have more time to burn on this, could you try the following on
>>>>> top? (If not, that is also fine, I will look into it myself on Monday)
>>>>> 
>>>>> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
>>>>> index 5ab13394dfd9..0f43f0751d47 100644
>>>>> --- a/scripts/kallsyms.c
>>>>> +++ b/scripts/kallsyms.c
>>>>> @@ -137,8 +137,10 @@ static int read_symbol(FILE *in, struct sym_entry *s)
>>>>>                sym++;
>>>>> 
>>>>>        /* Ignore most absolute/undefined (?) symbols. */
>>>>> -       if (strcmp(sym, "_text") == 0)
>>>>> +       if (strcmp(sym, "_text") == 0) {
>>>>>                _text = s->addr;
>>>>> +               stype = 'T';
>>>>> +       }
>>>>>        else if (check_symbol_range(sym, s->addr, text_ranges,
>>>>>                                    ARRAY_SIZE(text_ranges)) == 0)
>>>>>                /* nothing to do */;
>>>>> @@ -406,7 +408,7 @@ static void write_src(void)
>>>>> 
>>>>>        if (base_relative) {
>>>>>                output_label("kallsyms_relative_base");
>>>>> -               printf("\tPTR\t%#llx\n", relative_base);
>>>>> +               printf("\tPTR\t_text - %#llx\n", _text - relative_base);
>>>>>                printf("\n");
>>>>>        }
>>>> 
>>>> Does not help.
>>> 
>>> For x86? Or none of them?
>> 
>> I tested sparc32 and x86_64/nosmp. Doesn't help for any of them.
>> sparc32 has the following absolute symbols.
>> 
>> f035a420 A _etext
>> f03d9000 A _sdata
>> f03de8c4 A jiffies
>> f03f8860 A _edata
>> f03fc000 A __init_begin
>> f041bdc8 A __init_text_end
>> f0423000 A __bss_start
>> f0423000 A __init_end
>> f044457d A __bss_stop
>> f044457d A _end
> 
> Any clue why these don't get dropped? Am I missing something? Afaict A symbols get dropped unless they are whitelisted (i.e., the few ia64 ones)
> 

ok, never mind. it's the symbol range check.

anyway, i should have enough info now to get this sorted

thanks,
ard

>> This results in:
>> 
>> kallsyms failure: absolute symbol value 0xf035a420 out of range in relative mode
>> 
>> This is with binutils 2.22. I didn't test with binutils 2.25 for sparc, or re-test mips.
>> 
>> 
>> Looks like I'll need to add more test cases with binutils 2.22 vs. 2.25 for various
>> architectures, as well as more SMP vs. !SMP builds.
> 
> Thanks once again