[PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

Michal Suchánek msuchanek at suse.de
Wed May 5 04:08:18 AEST 2021


On Tue, May 04, 2021 at 11:11:25PM +0530, Naveen N. Rao wrote:
> Nicholas Piggin wrote:
> > Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> > > On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
> > > > On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
> > > > > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
> > > > > > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
> > > > > > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
> > > > > > >> Provide an option to use ELFv2 ABI for big endian builds. This works on
> > > > > > >> GCC and clang (since 2014). It is less well tested and supported by the
> > > > > > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
> > > > > > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
> > > > > > >> userspace.
> > > > > > > > > > Fixes BTFID failure on BE for me and the ELF ABIv2
> > > > kernel boots.
> > > > > > > > What's the BTFID failure? Anything we can do to fix it
> > > > on the v1 ABI or > > at least make it depend on BUILD_ELF_V2?
> > > > > > Looks like symbols are prefixed with a dot in ABIv1 and
> > > > BTFID tool is
> > > > > not aware of that. It can be disabled on ABIv1 easily.
> 
> Yes, I think BTF is generated by pahole, so we will need to add support for
> recognising dot symbols there.

There are symbols both with and without dot, and the dwarves
development is headed towards using the ones without dot. Not sure it's
the correct way to resolve it, though.
https://lore.kernel.org/lkml/8c3cbd22-eb26-ea8b-c8bb-35a629d6d2d8@kernel.org/

> 
> > > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > > > index 678c13967580..e703c26e9b80 100644
> > > > > --- a/lib/Kconfig.debug
> > > > > +++ b/lib/Kconfig.debug
> > > > > @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
> > > > >  	bool "Generate BTF typeinfo"
> > > > >  	depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
> > > > >  	depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> > > > > +	depends on !PPC64 || BUILD_ELF_V2
> > > > >  	help
> > > > >  	  Generate deduplicated BTF type information from DWARF debug info.
> > > > >  	  Turning this on expects presence of pahole tool, which will convert
> > > > > > > > > > > > > Tested-by: Michal Suchánek <msuchanek at suse.de>
> > > > > > > > > > Also can we enable mprofile on BE now?
> > > > > > > > > > I don't see anything endian-specific in the mprofile
> > > > code at a glance
> > > > > > > but don't have any idea how to test it.
> > > > > > > > AFAIK it's just a different ABI for the _mcount call so
> > > > just running
> > > > > > some ftrace and ftrace with call graph should test it reasonably well.
> > > > 
> > > > It does not crash and burn but there are some regressions from LE to BE
> > > > on the ftrace kernel selftest:
> > > > 
> > > > @@ -16,10 +16,10 @@
> > > >  [n] event tracing - enable/disable with event level files	[PASS]
> > > >  [n] event tracing - restricts events based on pid notrace filtering	[PASS]
> > > >  [n] event tracing - restricts events based on pid	[PASS]
> > > > -[n] event tracing - enable/disable with subsystem level files	[PASS]
> > > > +[n] event tracing - enable/disable with subsystem level files	[FAIL]
> > > >  [n] event tracing - enable/disable with top level files	[PASS]
> > > > -[n] Test trace_printk from module	[UNRESOLVED]
> > > > +[n] Test trace_printk from module	[FAIL]
> > > > -[n] ftrace - function graph filters with stack tracer	[PASS]
> > > > +[n] ftrace - function graph filters with stack tracer	[FAIL]
> > > >  [n] ftrace - function graph filters	[PASS]
> > > >  [n] ftrace - function trace with cpumask	[PASS]
> > > >  [n] ftrace - test for function event triggers	[PASS]
> > > > @@ -96,7 +96,8 @@
> > > >  [n] (instance)  event tracing - enable/disable with event level files	[PASS]
> > > >  [n] (instance)  event tracing - restricts events based on pid notrace filtering	[PASS]
> > > >  [n] (instance)  event tracing - restricts events based on pid	[PASS]
> > > > -[n] (instance)  event tracing - enable/disable with subsystem level files	[PASS]
> > > > +[n] (instance)  event tracing - enable/disable with subsystem level files	[FAIL]
> > > > +rmdir: failed to remove '/sys/kernel/tracing/instances/ftracetest.mceByV': Device or resource busy
> > > >  [n] (instance)  ftrace - test for function event triggers	[PASS]
> > > >  [n] (instance)  ftrace - function pid notrace filters	[PASS]
> > > >  [n] (instance)  ftrace - function pid filters	[PASS]
> > > > 
> > > > I needed to add a test timeout to get this far because
> > > > "event tracing - enable/disable with subsystem level files" gets stuck.
> 
> Does that test pass on LE for you? In the past, I have seen some lockups but
> will have to go revisit the tests...

Yes, it's one of the actual regressions where the test is not marked as
XFAIL, UNRESOLVED or UNSUPPORTED on LE.

> 
> > > 
> > > There is some regression from mprofile on BE ABIv2
> > > 
> > > --- ftraceBEv2.txt	2021-05-03 18:11:01.100000000 +0200
> > > +++ ftraceBE.mprofile.txt	2021-05-03 11:27:24.770000000 +0200
> > > @@ -19,7 +19,7 @@
> > >  [n] event tracing - enable/disable with subsystem level files	[FAIL]
> > >  [n] event tracing - enable/disable with top level files	[PASS]
> > >  [n] Test trace_printk from module	[FAIL]
> > > -[n] ftrace - function graph filters with stack tracer	[PASS]
> > > +[n] ftrace - function graph filters with stack tracer	[FAIL]
> > >  [n] ftrace - function graph filters	[PASS]
> > >  [n] ftrace - function trace with cpumask	[PASS]
> > >  [n] ftrace - test for function event triggers	[PASS]
> > > @@ -31,7 +31,7 @@
> > >  [n] ftrace - function profiler with function tracing	[PASS]
> > >  [n] ftrace - function profiling	[PASS]
> > >  [n] ftrace - test reading of set_ftrace_filter	[PASS]
> > > -[n] ftrace - Max stack tracer	[PASS]
> > > +[n] ftrace - Max stack tracer	[FAIL]
> > >  [n] ftrace - test for function traceon/off triggers	[PASS]
> > >  [n] ftrace - test tracing error log support	[PASS]
> > >  [n] Test creation and deletion of trace instances while setting an event	[PASS]
> > 
> > Hmm, I don't see an obvious case where the stack layout is based on
> > BE when it should be using ELF ABI version, or ftrace_64_mprofile.S
> > depends on LE. +Naveen
> 
> Yes, I don't think we ever enabled the stack tracer to work properly on LE
> and -mprofile-kernel. I will take a look tomorrow.

Right, "Max stack tracer" does not show as regression from LE to BE.

Thanks

Michal


More information about the Linuxppc-dev mailing list