Message ID | cover.1653398233.git.christophe.leroy@csgroup.eu (mailing list archive) |
---|---|
Headers | show |
Series | objtool: Enable and implement --mcount option on powerpc | expand |
Hi Christophe, On 24/05/22 18:47, Christophe Leroy wrote: > This draft series adds PPC32 support to Sathvika's series. > Verified on pmac32 on QEMU. > > It should in principle also work for PPC64 BE but for the time being > something goes wrong. In the beginning I had a segfaut hence the first > patch. But I still get no mcount section in the files. Since PPC64 BE uses older elfv1 ABI, it prepends a dot to symbols. And so, the relocation records in case of PPC64BE point to "._mcount", rather than just "_mcount". We should be looking for "._mcount" to be able to generate mcount_loc section in the files. Like: diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 70be5a72e838..7da5bf8c7236 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -2185,7 +2185,7 @@ static int classify_symbols(struct objtool_file *file) if (arch_is_retpoline(func)) func->retpoline_thunk = true; - if ((!strcmp(func->name, "__fentry__")) || (!strcmp(func->name, "_mcount"))) + if ((!strcmp(func->name, "__fentry__")) || (!strcmp(func->name, "_mcount")) || (!strcmp(func->name, "._mcount"))) func->fentry = true; if (is_profiling_func(func->name)) With this change, I could see __mcount_loc section being generated in individual ppc64be object files. - Sathvika
On Wed, May 25, 2022 at 03:44:04PM +0530, Sathvika Vasireddy wrote: > On 24/05/22 18:47, Christophe Leroy wrote: > >This draft series adds PPC32 support to Sathvika's series. > >Verified on pmac32 on QEMU. > > > >It should in principle also work for PPC64 BE but for the time being > >something goes wrong. In the beginning I had a segfaut hence the first > >patch. But I still get no mcount section in the files. > Since PPC64 BE uses older elfv1 ABI, it prepends a dot to symbols. > And so, the relocation records in case of PPC64BE point to "._mcount", > rather than just "_mcount". We should be looking for "._mcount" to be > able to generate mcount_loc section in the files. The dotted symbol is on the actual function. The "normal" symbol is on the "official procedure descriptor" (opd), which is what you get if you (in C) take the address of a function. A procedure descriptor holds one or two more pointers, the GOT and environment pointers. We don't use the environment one, but the GOT pointer is necessary everywhere :-) Segher
Hi Sathvika, Le 25/05/2022 à 12:14, Sathvika Vasireddy a écrit : > Hi Christophe, > > On 24/05/22 18:47, Christophe Leroy wrote: >> This draft series adds PPC32 support to Sathvika's series. >> Verified on pmac32 on QEMU. >> >> It should in principle also work for PPC64 BE but for the time being >> something goes wrong. In the beginning I had a segfaut hence the first >> patch. But I still get no mcount section in the files. > Since PPC64 BE uses older elfv1 ABI, it prepends a dot to symbols. > And so, the relocation records in case of PPC64BE point to "._mcount", > rather than just "_mcount". We should be looking for "._mcount" to be > able to generate mcount_loc section in the files. > > Like: > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 70be5a72e838..7da5bf8c7236 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -2185,7 +2185,7 @@ static int classify_symbols(struct objtool_file > *file) > if (arch_is_retpoline(func)) > func->retpoline_thunk = true; > > - if ((!strcmp(func->name, "__fentry__")) || > (!strcmp(func->name, "_mcount"))) > + if ((!strcmp(func->name, "__fentry__")) || > (!strcmp(func->name, "_mcount")) || (!strcmp(func->name, "._mcount"))) > func->fentry = true; > > if (is_profiling_func(func->name)) > > > With this change, I could see __mcount_loc section being > generated in individual ppc64be object files. > Or should we implement an equivalent of arch_ftrace_match_adjust() in objtool ? Christophe
On 25/05/22 23:09, Christophe Leroy wrote: > Hi Sathvika, > > Le 25/05/2022 à 12:14, Sathvika Vasireddy a écrit : >> Hi Christophe, >> >> On 24/05/22 18:47, Christophe Leroy wrote: >>> This draft series adds PPC32 support to Sathvika's series. >>> Verified on pmac32 on QEMU. >>> >>> It should in principle also work for PPC64 BE but for the time being >>> something goes wrong. In the beginning I had a segfaut hence the first >>> patch. But I still get no mcount section in the files. >> Since PPC64 BE uses older elfv1 ABI, it prepends a dot to symbols. >> And so, the relocation records in case of PPC64BE point to "._mcount", >> rather than just "_mcount". We should be looking for "._mcount" to be >> able to generate mcount_loc section in the files. >> >> Like: >> >> diff --git a/tools/objtool/check.c b/tools/objtool/check.c >> index 70be5a72e838..7da5bf8c7236 100644 >> --- a/tools/objtool/check.c >> +++ b/tools/objtool/check.c >> @@ -2185,7 +2185,7 @@ static int classify_symbols(struct objtool_file >> *file) >> if (arch_is_retpoline(func)) >> func->retpoline_thunk = true; >> >> - if ((!strcmp(func->name, "__fentry__")) || >> (!strcmp(func->name, "_mcount"))) >> + if ((!strcmp(func->name, "__fentry__")) || >> (!strcmp(func->name, "_mcount")) || (!strcmp(func->name, "._mcount"))) >> func->fentry = true; >> >> if (is_profiling_func(func->name)) >> >> >> With this change, I could see __mcount_loc section being >> generated in individual ppc64be object files. >> > Or should we implement an equivalent of arch_ftrace_match_adjust() in > objtool ? Yeah, I think it makes more sense if we make it arch specific. Thanks for the suggestion. I'll make this change in next revision :-) - Sathvika
Le 25/05/2022 à 20:12, Sathvika Vasireddy a écrit : > > On 25/05/22 23:09, Christophe Leroy wrote: >> Hi Sathvika, >> >> Le 25/05/2022 à 12:14, Sathvika Vasireddy a écrit : >>> Hi Christophe, >>> >>> On 24/05/22 18:47, Christophe Leroy wrote: >>>> This draft series adds PPC32 support to Sathvika's series. >>>> Verified on pmac32 on QEMU. >>>> >>>> It should in principle also work for PPC64 BE but for the time being >>>> something goes wrong. In the beginning I had a segfaut hence the first >>>> patch. But I still get no mcount section in the files. >>> Since PPC64 BE uses older elfv1 ABI, it prepends a dot to symbols. >>> And so, the relocation records in case of PPC64BE point to "._mcount", >>> rather than just "_mcount". We should be looking for "._mcount" to be >>> able to generate mcount_loc section in the files. >>> >>> Like: >>> >>> diff --git a/tools/objtool/check.c b/tools/objtool/check.c >>> index 70be5a72e838..7da5bf8c7236 100644 >>> --- a/tools/objtool/check.c >>> +++ b/tools/objtool/check.c >>> @@ -2185,7 +2185,7 @@ static int classify_symbols(struct objtool_file >>> *file) >>> if (arch_is_retpoline(func)) >>> func->retpoline_thunk = true; >>> >>> - if ((!strcmp(func->name, "__fentry__")) || >>> (!strcmp(func->name, "_mcount"))) >>> + if ((!strcmp(func->name, "__fentry__")) || >>> (!strcmp(func->name, "_mcount")) || (!strcmp(func->name, "._mcount"))) >>> func->fentry = true; >>> >>> if (is_profiling_func(func->name)) >>> >>> >>> With this change, I could see __mcount_loc section being >>> generated in individual ppc64be object files. >>> >> Or should we implement an equivalent of arch_ftrace_match_adjust() in >> objtool ? > > Yeah, I think it makes more sense if we make it arch specific. > Thanks for the suggestion. I'll make this change in next revision :-) > Do you have any idea when you plan to send next revision ? I'm really looking forward to submitting the inline static calls on top of your series. Thanks Christophe
Hi Christophe, On 15/06/22 21:33, Christophe Leroy wrote: > Do you have any idea when you plan to send next revision ? > > I'm really looking forward to submitting the inline static calls on top > of your series. I'm planning to send RFC v3 next week. - Sathvika
Hi Sathvika Le 18/06/2022 à 06:56, Sathvika Vasireddy a écrit : > Hi Christophe, > > On 15/06/22 21:33, Christophe Leroy wrote: >> Do you have any idea when you plan to send next revision ? >> >> I'm really looking forward to submitting the inline static calls on top >> of your series. > > I'm planning to send RFC v3 next week. > Is everything going ok ? Don't hesitate if you need help. Christophe
Hi Christophe,
On 24/06/22 12:38, Christophe Leroy wrote:
> Is everything going ok ? Don't hesitate if you need help.
Yeah, sure. Thanks!
I just posted RFC v3 here:
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/20220624183238.388144-1-sv@linux.ibm.com/