[RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[Tiezhu Yang]

Select ARCH_WANT_FRAME_POINTERS to fix the following build error under
CONFIG_DEBUG_ATOMIC_SLEEP:

  CC      arch/mips/kernel/signal.o
{standard input}: Assembler messages:
{standard input}:1775: Error: Unable to parse register name $fp
scripts/Makefile.build:283: recipe for target 'arch/mips/kernel/signal.o' failed
make[2]: *** [arch/mips/kernel/signal.o] Error 1
scripts/Makefile.build:500: recipe for target 'arch/mips/kernel' failed
make[1]: *** [arch/mips/kernel] Error 2
Makefile:1799: recipe for target 'arch/mips' failed
make: *** [arch/mips] Error 2

I think it is useful to get debugging information as described in the
following texts:

lib/Kconfig.debug
config FRAME_POINTER
        bool "Compile the kernel with frame pointers"
        ...
        default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
        help
          If you say Y here the resulting kernel image will be slightly
          larger and slower, but it gives very useful debugging information
          in case of kernel bugs. (precise oopses/stacktraces/warnings)

Documentation/dev-tools/kgdb.rst
This option inserts code to into the compiled executable which saves
the frame information in registers or on the stack at different points
which allows a debugger such as gdb to more accurately construct stack
back traces while debugging the kernel.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ddaff19..4a4c791 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -15,6 +15,7 @@ config MIPS
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+	select ARCH_WANT_FRAME_POINTERS
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select BUILDTIME_TABLE_SORT
 	select CLONE_BACKWARDS
-- 
2.1.0

Re: [RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[Sergei Shtylyov]

Hello!

On 16.11.2020 8:03, Tiezhu Yang wrote:

> Select ARCH_WANT_FRAME_POINTERS to fix the following build error under
> CONFIG_DEBUG_ATOMIC_SLEEP:
> 
>    CC      arch/mips/kernel/signal.o
> {standard input}: Assembler messages:
> {standard input}:1775: Error: Unable to parse register name $fp
> scripts/Makefile.build:283: recipe for target 'arch/mips/kernel/signal.o' failed
> make[2]: *** [arch/mips/kernel/signal.o] Error 1
> scripts/Makefile.build:500: recipe for target 'arch/mips/kernel' failed
> make[1]: *** [arch/mips/kernel] Error 2
> Makefile:1799: recipe for target 'arch/mips' failed
> make: *** [arch/mips] Error 2
> 
> I think it is useful to get debugging information as described in the
> following texts:
> 
> lib/Kconfig.debug
> config FRAME_POINTER
>          bool "Compile the kernel with frame pointers"
>          ...
>          default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
>          help
>            If you say Y here the resulting kernel image will be slightly
>            larger and slower, but it gives very useful debugging information
>            in case of kernel bugs. (precise oopses/stacktraces/warnings)
> 
> Documentation/dev-tools/kgdb.rst
> This option inserts code to into the compiled executable which saves

    So to or into? :-)

> the frame information in registers or on the stack at different points
> which allows a debugger such as gdb to more accurately construct stack
> back traces while debugging the kernel.
> 
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
[...]

MBR, Sergei

Re: [RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[Tiezhu Yang]

On 11/16/2020 05:08 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 16.11.2020 8:03, Tiezhu Yang wrote:
>
>> Select ARCH_WANT_FRAME_POINTERS to fix the following build error under
>> CONFIG_DEBUG_ATOMIC_SLEEP:
>>
>>    CC      arch/mips/kernel/signal.o
>> {standard input}: Assembler messages:
>> {standard input}:1775: Error: Unable to parse register name $fp
>> scripts/Makefile.build:283: recipe for target 
>> 'arch/mips/kernel/signal.o' failed
>> make[2]: *** [arch/mips/kernel/signal.o] Error 1
>> scripts/Makefile.build:500: recipe for target 'arch/mips/kernel' failed
>> make[1]: *** [arch/mips/kernel] Error 2
>> Makefile:1799: recipe for target 'arch/mips' failed
>> make: *** [arch/mips] Error 2
>>
>> I think it is useful to get debugging information as described in the
>> following texts:
>>
>> lib/Kconfig.debug
>> config FRAME_POINTER
>>          bool "Compile the kernel with frame pointers"
>>          ...
>>          default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
>>          help
>>            If you say Y here the resulting kernel image will be slightly
>>            larger and slower, but it gives very useful debugging 
>> information
>>            in case of kernel bugs. (precise oopses/stacktraces/warnings)
>>
>> Documentation/dev-tools/kgdb.rst
>> This option inserts code to into the compiled executable which saves
>
>    So to or into? :-)

Hi Sergei,

Thanks for pointing that out，this may be a typo which should be "into".
I will update the commit message to correct it.

Thanks,
Tiezhu

>
>> the frame information in registers or on the stack at different points
>> which allows a debugger such as gdb to more accurately construct stack
>> back traces while debugging the kernel.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> [...]
>
> MBR, Sergei

Re: [RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[Sergei Shtylyov]

On 16.11.2020 12:47, Tiezhu Yang wrote:

[...]
>>> Select ARCH_WANT_FRAME_POINTERS to fix the following build error under
>>> CONFIG_DEBUG_ATOMIC_SLEEP:
>>>
>>>    CC      arch/mips/kernel/signal.o
>>> {standard input}: Assembler messages:
>>> {standard input}:1775: Error: Unable to parse register name $fp
>>> scripts/Makefile.build:283: recipe for target 'arch/mips/kernel/signal.o' 
>>> failed
>>> make[2]: *** [arch/mips/kernel/signal.o] Error 1
>>> scripts/Makefile.build:500: recipe for target 'arch/mips/kernel' failed
>>> make[1]: *** [arch/mips/kernel] Error 2
>>> Makefile:1799: recipe for target 'arch/mips' failed
>>> make: *** [arch/mips] Error 2
>>>
>>> I think it is useful to get debugging information as described in the
>>> following texts:
>>>
>>> lib/Kconfig.debug
>>> config FRAME_POINTER
>>>          bool "Compile the kernel with frame pointers"
>>>          ...
>>>          default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
>>>          help
>>>            If you say Y here the resulting kernel image will be slightly
>>>            larger and slower, but it gives very useful debugging information
>>>            in case of kernel bugs. (precise oopses/stacktraces/warnings)
>>>
>>> Documentation/dev-tools/kgdb.rst
>>> This option inserts code to into the compiled executable which saves
>>
>>    So to or into? :-)
> 
> Hi Sergei,
> 
> Thanks for pointing that out，this may be a typo which should be "into".

    Oops, I didn't realize it was a quote from the KGDB docs... :-)

> I will update the commit message to correct it.

    Thank you!

> Thanks,
> Tiezhu

[...]

MBR, Sergei

Re: [RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[Maciej W. Rozycki]

On Mon, 16 Nov 2020, Tiezhu Yang wrote:

> Select ARCH_WANT_FRAME_POINTERS to fix the following build error under
> CONFIG_DEBUG_ATOMIC_SLEEP:
> 
>   CC      arch/mips/kernel/signal.o
> {standard input}: Assembler messages:
> {standard input}:1775: Error: Unable to parse register name $fp
> scripts/Makefile.build:283: recipe for target 'arch/mips/kernel/signal.o' failed
> make[2]: *** [arch/mips/kernel/signal.o] Error 1
> scripts/Makefile.build:500: recipe for target 'arch/mips/kernel' failed
> make[1]: *** [arch/mips/kernel] Error 2
> Makefile:1799: recipe for target 'arch/mips' failed
> make: *** [arch/mips] Error 2

 Your change description does not explain to me what is going on here I am 
afraid, and based on it I am unable to determine if it is fit for purpose.  

 It seems to me like your change papers over an issue by changing code 
generation somehow with the kernel configuration option selected so that 
invalid assembly is not produced anymore while invalid assembly should not 
happen in the first place regardless of the configuration.

 In particular `$fp' is a standard assembly alias for `$30' aka `$s8' and 
it is expected to work where `$30' or indeed any general-purpose register 
would:

#define SYMBOLIC_REGISTER_NAMES \
[...]
    {"$s8",	RTYPE_GP | 30}, \
    {"$fp",	RTYPE_GP | 30}, \
    {"$ra",	RTYPE_GP | 31}

(from gas/config/tc-mips.c) so please show us what the assembly line GAS 
chokes on looks like in your case.

> Documentation/dev-tools/kgdb.rst
> This option inserts code to into the compiled executable which saves
> the frame information in registers or on the stack at different points
> which allows a debugger such as gdb to more accurately construct stack
> back traces while debugging the kernel.

 Hmm, this is what DWARF debug information is for in the context of GDB, 
and I certainly used to use GDB to debug standard MIPS/Linux kernels built 
without the use of a separate frame pointer register (which there wasn't a 
kernel configuration option for back then, though which you obviously 
still could try to enforce with the use of `-fno-omit-frame-pointer' via 
CFLAGS) using JTAG probes or simulation some 15 years ago.

 And given the variable layout of the MIPS stack frame (unlike with some 
psABIs, e.g. Power) the use of `$fp' alone does not let you reconstruct a 
backtrace, because you cannot infer from the value of `$fp' where to 
retrieve the value of `$ra' from.  For that you need debug information.

 So the information you quote seems misleading or missing the context.

 NB hardly any MIPS software uses the frame pointer register and all is 
debuggable regardless; the only actual use for $fp is `alloca', VLAs or 
similar dynamic frame arrangements.

 So what actual problem are you trying to solve, except for the assembly 
error, and what is your use case for `$fp' with MIPS kernel debugging?

  Maciej

Re: [RFC PATCH] MIPS: Kconfig: Select ARCH_WANT_FRAME_POINTERS

[Tiezhu Yang]

On 11/21/2020 06:37 AM, Maciej W. Rozycki wrote:
> On Mon, 16 Nov 2020, Tiezhu Yang wrote:
>
>> Select ARCH_WANT_FRAME_POINTERS to fix the following build error under
>> CONFIG_DEBUG_ATOMIC_SLEEP:
>>
>>    CC      arch/mips/kernel/signal.o
>> {standard input}: Assembler messages:
>> {standard input}:1775: Error: Unable to parse register name $fp
>> scripts/Makefile.build:283: recipe for target 'arch/mips/kernel/signal.o' failed
>> make[2]: *** [arch/mips/kernel/signal.o] Error 1
>> scripts/Makefile.build:500: recipe for target 'arch/mips/kernel' failed
>> make[1]: *** [arch/mips/kernel] Error 2
>> Makefile:1799: recipe for target 'arch/mips' failed
>> make: *** [arch/mips] Error 2
>   Your change description does not explain to me what is going on here I am
> afraid, and based on it I am unable to determine if it is fit for purpose.
>
>   It seems to me like your change papers over an issue by changing code
> generation somehow with the kernel configuration option selected so that
> invalid assembly is not produced anymore while invalid assembly should not
> happen in the first place regardless of the configuration.
>
>   In particular `$fp' is a standard assembly alias for `$30' aka `$s8' and
> it is expected to work where `$30' or indeed any general-purpose register
> would:
>
> #define SYMBOLIC_REGISTER_NAMES \
> [...]
>      {"$s8",	RTYPE_GP | 30}, \
>      {"$fp",	RTYPE_GP | 30}, \
>      {"$ra",	RTYPE_GP | 31}
>
> (from gas/config/tc-mips.c) so please show us what the assembly line GAS
> chokes on looks like in your case.
>
>> Documentation/dev-tools/kgdb.rst
>> This option inserts code to into the compiled executable which saves
>> the frame information in registers or on the stack at different points
>> which allows a debugger such as gdb to more accurately construct stack
>> back traces while debugging the kernel.
>   Hmm, this is what DWARF debug information is for in the context of GDB,
> and I certainly used to use GDB to debug standard MIPS/Linux kernels built
> without the use of a separate frame pointer register (which there wasn't a
> kernel configuration option for back then, though which you obviously
> still could try to enforce with the use of `-fno-omit-frame-pointer' via
> CFLAGS) using JTAG probes or simulation some 15 years ago.
>
>   And given the variable layout of the MIPS stack frame (unlike with some
> psABIs, e.g. Power) the use of `$fp' alone does not let you reconstruct a
> backtrace, because you cannot infer from the value of `$fp' where to
> retrieve the value of `$ra' from.  For that you need debug information.
>
>   So the information you quote seems misleading or missing the context.
>
>   NB hardly any MIPS software uses the frame pointer register and all is
> debuggable regardless; the only actual use for $fp is `alloca', VLAs or
> similar dynamic frame arrangements.
>
>   So what actual problem are you trying to solve, except for the assembly
> error, and what is your use case for `$fp' with MIPS kernel debugging?

Hi Maciej,

Thank you very much for your reply and detailed explanation.

The initial aim of this patch is to fix the build error.
I found this build error used with gcc 4.9.4.
I try it used with gcc 7.3.1 and it has no problem.
We can use new gcc version to avoid this build error.

The other commit message about config and kgdb seems no
related with the above build error, just give more info
to discuss.

As I see it now, this RFC patch is meaningless, so please
ignore it and thank you again.

Thanks,
Tiezhu

>
>    Maciej