arch/arm/kernel/setup.c does not compile at -O0

arch/arm/kernel/setup.c does not compile at -O0

[Mason]

Hello everyone,

I'm trying to debug a live kernel (v3.14) using a DS-5 JTAG probe.

In order to make the control flow easier to follow, I disabled
optimizations by adding

  subdir-ccflags-y := -O0

to arch/arm/kernel/Makefile

With that change, linking fails:

arch/arm/kernel/setup.c:924: undefined reference to `psci_smp_ops'

      if (psci_smp_available())
        smp_set_ops(&psci_smp_ops);

#ifdef CONFIG_ARM_PSCI
void psci_init(void);
bool psci_smp_available(void);
#else
static inline void psci_init(void) { }
static inline bool psci_smp_available(void) { return false; }
#endif

The optimizer is able to remove the entire block, but this
does not happen when optimizations are disabled.

Is compiling at -O0 not supported?


My larger problem: the DS-5 debugger refuses to show the value
of local variables. As a work-around, I can make some variables
global, but it's really inconvenient.

I checked that CONFIG_FRAME_POINTER=y
and source files are compiled with -g

arm-linux-gnueabihf-gcc -Wp,-MD,init/.main.o.d  -nostdinc -isystem /opt/gcc-linaro-2014.11/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/include -I/opt/linux/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/opt/linux/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/opt/linux/include/uapi -Iinclude/generated/uapi -include /opt/linux/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-tangox/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -std=gnu89 -O2 -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-
 p
ointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -O0    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)"  -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o init/main.o init/main.c


Any idea how I can get DS-5 to properly handle local variables?


I'm trying to convert an old-style board config to a device tree,
and I can't even get serial to work... :-(

Regards.

arch/arm/kernel/setup.c does not compile at -O0

[Robin Murphy]

On 30/07/15 13:53, Mason wrote:
> Hello everyone,
>
> I'm trying to debug a live kernel (v3.14) using a DS-5 JTAG probe.
>
> In order to make the control flow easier to follow, I disabled
> optimizations by adding
>
>    subdir-ccflags-y := -O0
>
> to arch/arm/kernel/Makefile
>
> With that change, linking fails:
>
> arch/arm/kernel/setup.c:924: undefined reference to `psci_smp_ops'
>
>        if (psci_smp_available())
>          smp_set_ops(&psci_smp_ops);
>
> #ifdef CONFIG_ARM_PSCI
> void psci_init(void);
> bool psci_smp_available(void);
> #else
> static inline void psci_init(void) { }
> static inline bool psci_smp_available(void) { return false; }
> #endif
>
> The optimizer is able to remove the entire block, but this
> does not happen when optimizations are disabled.
>
> Is compiling at -O0 not supported?
>
>
> My larger problem: the DS-5 debugger refuses to show the value
> of local variables. As a work-around, I can make some variables
> global, but it's really inconvenient.
>
> I checked that CONFIG_FRAME_POINTER=y
> and source files are compiled with -g
>
> arm-linux-gnueabihf-gcc -Wp,-MD,init/.main.o.d  -nostdinc -isystem /opt/gcc-linaro-2014.11/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/include -I/opt/linux/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/opt/linux/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/opt/linux/include/uapi -Iinclude/generated/uapi -include /opt/linux/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-tangox/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -std=gnu89 -O2 -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno
-
>   p
> ointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -O0    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)"  -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o init/main.o init/main.c
>
>
> Any idea how I can get DS-5 to properly handle local variables?

I carry a patch locally reverting 2062afb4f804 - at least on arm64, the 
debugger manages to resolve optimised locals considerably better without 
the -fno-var-tracking-assignments option. The Kconfig "Generate dwarf4 
debug info" option is a good idea, and "Generate readable assembly code" 
sometimes helps a bit too.

Whilst in general -O0 isn't going to work, I've had some success using 
"__attribute__ ((optimize(0)))" on individual functions of interest.

Hope that's of some help.

Robin.

>
>
> I'm trying to convert an old-style board config to a device tree,
> and I can't even get serial to work... :-(
>
> Regards.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

arch/arm/kernel/setup.c does not compile at -O0

[Mason]

On 30/07/2015 15:14, Robin Murphy wrote:

> On 30/07/15 13:53, Mason wrote:
> 
>> Any idea how I can get DS-5 to properly handle local variables?
> 
> I carry a patch locally reverting 2062afb4f804 - at least on arm64, the 
> debugger manages to resolve optimised locals considerably better without 
> the -fno-var-tracking-assignments option. The Kconfig "Generate dwarf4 
> debug info" option is a good idea, and "Generate readable assembly code" 
> sometimes helps a bit too.

I reverted 2062afb4f804 (I'm using 4.9.3 so I think it's safe)

AFAICT, config DEBUG_INFO_DWARF4 isn't available in 3.14
(I think bfaf2dd3509b was included in 3.16)

But the problem seems to be on a higher level. My debugger
just doesn't see ANY local variable whatsoever.

For example, if I break in serial8250_probe, step past the
initializations, then the Eclipse "Variables" tab states
Locals: 0 variables (as it does everywhere, mind you).

If I try to print from the "Commands" tab:

print p
ERROR(EXP8): Could not find the symbol "p"
print irqflag
ERROR(EXP8): Could not find the symbol "irqflag"

I'm doing wrong something fundamental.

This is my work flow:

Start the system, interrupt it in Uboot
Connect the DS-5 probe
Set a HW breakpoint at the address of start_kernel
Let Uboot load the kernel
When the breakpoint is hit, load the symbols with:
  add-symbol-file /opt/linux-3.14/vmlinux

=> Is vmlinux supposed to contain the debug info for the
local variables? (I mean 'automatic' variables, in the
C sense.)

> Whilst in general -O0 isn't going to work, I've had some success using 
> "__attribute__ ((optimize(0)))" on individual functions of interest.

This will work at the function granularity?

Regards.

arch/arm/kernel/setup.c does not compile at -O0

[Mason]

On 30/07/2015 15:58, Mason wrote:

> On 30/07/2015 15:14, Robin Murphy wrote:
> 
>> On 30/07/15 13:53, Mason wrote:
>>
>>> Any idea how I can get DS-5 to properly handle local variables?
>>
>> I carry a patch locally reverting 2062afb4f804 - at least on arm64, the 
>> debugger manages to resolve optimised locals considerably better without 
>> the -fno-var-tracking-assignments option. The Kconfig "Generate dwarf4 
>> debug info" option is a good idea, and "Generate readable assembly code" 
>> sometimes helps a bit too.
> 
> I reverted 2062afb4f804 (I'm using 4.9.3 so I think it's safe)
> 
> AFAICT, config DEBUG_INFO_DWARF4 isn't available in 3.14
> (I think bfaf2dd3509b was included in 3.16)
> 
> But the problem seems to be on a higher level. My debugger
> just doesn't see ANY local variable whatsoever.
> 
> For example, if I break in serial8250_probe, step past the
> initializations, then the Eclipse "Variables" tab states
> Locals: 0 variables (as it does everywhere, mind you).
> 
> If I try to print from the "Commands" tab:
> 
> print p
> ERROR(EXP8): Could not find the symbol "p"
> print irqflag
> ERROR(EXP8): Could not find the symbol "irqflag"
> 
> I'm doing wrong something fundamental.
> 
> This is my work flow:
> 
> Start the system, interrupt it in Uboot
> Connect the DS-5 probe
> Set a HW breakpoint at the address of start_kernel
> Let Uboot load the kernel
> When the breakpoint is hit, load the symbols with:
>   add-symbol-file /opt/linux-3.14/vmlinux
> 
> => Is vmlinux supposed to contain the debug info for the
> local variables? (I mean 'automatic' variables, in the
> C sense.)

I went all-in, and set

KBUILD_CFLAGS	+= -g3

in the top-level Makefile.

Still no local variables shown.


http://eli.thegreenplace.net/2011/02/07/how-debuggers-work-part-3-debugging-information/

$ arm-linux-gnueabihf-objdump -x vmlinux | grep "\.debug"
 25 .debug_line    0041075d  00000000  00000000  003679d3  2**0
 26 .debug_info    01a54a2f  00000000  00000000  00778130  2**0
 27 .debug_abbrev  000edef8  00000000  00000000  021ccb5f  2**0
 28 .debug_aranges 00007508  00000000  00000000  022baa58  2**3
 29 .debug_ranges  000ab8c8  00000000  00000000  022c1f60  2**3
 30 .debug_frame   000a5864  00000000  00000000  0236d828  2**2
 31 .debug_str     001aa5cd  00000000  00000000  0241308c  2**0
 32 .debug_macro   0041d5d4  00000000  00000000  025bd659  2**0
 33 .debug_loc     00427524  00000000  00000000  029dac2d  2**0

$ arm-linux-gnueabihf-objdump --dwarf=info vmlinux | wc
12972723 60571026 650075352

Seems there is a lot of information available, but the debugger
doesn't seem to be able to make use of it...

To take my serial8250_probe example:

static int serial8250_probe(struct platform_device *dev)
{
	struct plat_serial8250_port *p = dev_get_platdata(&dev->dev);
	struct uart_8250_port uart;
	int ret, i, irqflag = 0;

 <1><101ea81>: Abbrev Number: 76 (DW_TAG_subprogram)
    <101ea82>   DW_AT_name        : (indirect string, offset: 0x152f7a): serial8250_probe       
    <101ea86>   DW_AT_decl_file   : 1   
    <101ea87>   DW_AT_decl_line   : 3089        
    <101ea89>   DW_AT_prototyped  : 1   
    <101ea89>   DW_AT_type        : <0x100ec7a> 
    <101ea8d>   DW_AT_low_pc      : 0xc018e0f4  
    <101ea91>   DW_AT_high_pc     : 0x228       
    <101ea95>   DW_AT_frame_base  : 1 byte block: 9c    (DW_OP_call_frame_cfa)
    <101ea97>   DW_AT_GNU_all_tail_call_sites: 1        
    <101ea97>   DW_AT_sibling     : <0x101eb39> 
 <2><101ea9b>: Abbrev Number: 77 (DW_TAG_formal_parameter)
    <101ea9c>   DW_AT_name        : dev 
    <101eaa0>   DW_AT_decl_file   : 1   
    <101eaa1>   DW_AT_decl_line   : 3089        
    <101eaa3>   DW_AT_type        : <0x10127be> 
    <101eaa7>   DW_AT_location    : 3 byte block: 91 e4 7d      (DW_OP_fbreg: -284)
 <2><101eaab>: Abbrev Number: 88 (DW_TAG_variable)
    <101eaac>   DW_AT_name        : p   
    <101eaae>   DW_AT_decl_file   : 1   
    <101eaaf>   DW_AT_decl_line   : 3091        
    <101eab1>   DW_AT_type        : <0x101eb39> 
    <101eab5>   DW_AT_location    : 2 byte block: 91 6c         (DW_OP_fbreg: -20)
 <2><101eab8>: Abbrev Number: 89 (DW_TAG_variable)
    <101eab9>   DW_AT_name        : (indirect string, offset: 0x150dd5): uart   
    <101eabd>   DW_AT_decl_file   : 1   
    <101eabe>   DW_AT_decl_line   : 3092        
    <101eac0>   DW_AT_type        : <0x101846a> 
    <101eac4>   DW_AT_location    : 3 byte block: 91 e8 7d      (DW_OP_fbreg: -280)
 <2><101eac8>: Abbrev Number: 88 (DW_TAG_variable)
    <101eac9>   DW_AT_name        : ret 
    <101eacd>   DW_AT_decl_file   : 1   
    <101eace>   DW_AT_decl_line   : 3093        
    <101ead0>   DW_AT_type        : <0x100ec7a> 
    <101ead4>   DW_AT_location    : 2 byte block: 91 58         (DW_OP_fbreg: -40)
 <2><101ead7>: Abbrev Number: 88 (DW_TAG_variable)
    <101ead8>   DW_AT_name        : i   
    <101eada>   DW_AT_decl_file   : 1   
    <101eadb>   DW_AT_decl_line   : 3093        
    <101eadd>   DW_AT_type        : <0x100ec7a> 
    <101eae1>   DW_AT_location    : 2 byte block: 91 68         (DW_OP_fbreg: -24)
 <2><101eae4>: Abbrev Number: 89 (DW_TAG_variable)
    <101eae5>   DW_AT_name        : (indirect string, offset: 0x151780): irqflag        
    <101eae9>   DW_AT_decl_file   : 1   
    <101eaea>   DW_AT_decl_line   : 3093        
    <101eaec>   DW_AT_type        : <0x100ec7a> 
    <101eaf0>   DW_AT_location    : 2 byte block: 91 64         (DW_OP_fbreg: -28)


I'm running out of ideas. I'll give DWARF 4 a try.

My debugger is ARM DS-5 v5.13 (Build 1622)

Regards.

arch/arm/kernel/setup.c does not compile at -O0

[Mason]

On 30/07/2015 15:58, Mason wrote:

> But the problem seems to be on a higher level. My debugger
> just doesn't see ANY local variable whatsoever.

I found the magic setting!

NB: I'm using gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11)

If I add either:

KBUILD_CFLAGS  += $(call cc-option, -gdwarf-2,)
or
KBUILD_CFLAGS  += $(call cc-option, -gdwarf-3,)

to my top-level Makefile, then DS-5 is able to display local variables.


However, if I add:

KBUILD_CFLAGS  += $(call cc-option, -gdwarf-4,)

or nothing at all, DS-5 just ignores local variables.


It appears that "gcc -g" and "gcc -gdwarf-2 -g" generate different
debugging information... What debugging format does "gcc -g" use?
(Not DWARF, apparently.)

I'll try setting KBUILD_CFLAGS += -gdwarf-2
instead of $(call cc-option, -gdwarf-2,)
=> Yes, that works too.
Does anyone know the difference?

So basically, I'm now using this patch locally:

$ git diff Makefile 
diff --git a/Makefile b/Makefile
index f9041e6d4d19..f79c480f8922 100644
--- a/Makefile
+++ b/Makefile
@@ -641,10 +641,8 @@ KBUILD_CFLAGS      += -fomit-frame-pointer
 endif
 endif
 
-KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
-
 ifdef CONFIG_DEBUG_INFO
-KBUILD_CFLAGS  += -g
+KBUILD_CFLAGS  += -gdwarf-3
 KBUILD_AFLAGS  += -Wa,--gdwarf-2
 endif
 

Regards.

arch/arm/kernel/setup.c does not compile at -O0

[Mason]

On 30/07/2015 18:09, Mason wrote:

> It appears that "gcc -g" and "gcc -gdwarf-2 -g" generate different
> debugging information... What debugging format does "gcc -g" use?

For the sake of completeness.

My compiler:
gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11)

-gdwarf-2 generates DWARF 2
-gdwarf-3 generates DWARF 3
-g generates DWARF 4

It seems that my aging version of DS-5
"ARM DS-5 Development Studio version 5.13 build 1622" dated 2012/12/14
did NOT support DWARF 4 debug format...
(at least not the DWARF 4 generated by gcc 4.9.3)

which is weird because the changelog for 5.12 states:
"Support for DWARF4 debug information generated by gcc 4.5 releases"

> I'm now using this patch locally:
> 
> $ git diff Makefile
> diff --git a/Makefile b/Makefile
> index f9041e6d4d19..f79c480f8922 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -641,10 +641,8 @@ KBUILD_CFLAGS      += -fomit-frame-pointer
>  endif
>  endif
>  
> -KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
> -
>  ifdef CONFIG_DEBUG_INFO
> -KBUILD_CFLAGS  += -g
> +KBUILD_CFLAGS  += -gdwarf-3
>  KBUILD_AFLAGS  += -Wa,--gdwarf-2
>  endif

Regards.

arch/arm/kernel/setup.c does not compile at -O0

[Russell King - ARM Linux]

On Thu, Jul 30, 2015 at 02:53:54PM +0200, Mason wrote:
> Is compiling at -O0 not supported?

Much of the kernel does not support building at -O0.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

arch/arm/kernel/setup.c does not compile at -O0

[Suman Tripathi]

Hi,

On Thu, Jul 30, 2015 at 6:23 PM, Mason <slash.tmp@free.fr> wrote:
>
> Hello everyone,
>
> I'm trying to debug a live kernel (v3.14) using a DS-5 JTAG probe.
>
> In order to make the control flow easier to follow, I disabled
> optimizations by adding
>
>   subdir-ccflags-y := -O0
>
> to arch/arm/kernel/Makefile
>
> With that change, linking fails:
>
> arch/arm/kernel/setup.c:924: undefined reference to `psci_smp_ops'
>
>       if (psci_smp_available())
>         smp_set_ops(&psci_smp_ops);
>
> #ifdef CONFIG_ARM_PSCI
> void psci_init(void);
> bool psci_smp_available(void);
> #else
> static inline void psci_init(void) { }
> static inline bool psci_smp_available(void) { return false; }
> #endif
>
> The optimizer is able to remove the entire block, but this
> does not happen when optimizations are disabled.
>
> Is compiling at -O0 not supported?

If you have inline functions, it won't compile at -O0

>
>
> My larger problem: the DS-5 debugger refuses to show the value
> of local variables. As a work-around, I can make some variables
> global, but it's really inconvenient.
>
> I checked that CONFIG_FRAME_POINTER=y
> and source files are compiled with -g
>
> arm-linux-gnueabihf-gcc -Wp,-MD,init/.main.o.d  -nostdinc -isystem /opt/gcc-linaro-2014.11/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/include -I/opt/linux/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/opt/linux/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/opt/linux/include/uapi -Iinclude/generated/uapi -include /opt/linux/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-tangox/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -std=gnu89 -O2 -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-
>  p
> ointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -O0    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)"  -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o init/main.o init/main.c
>
>
> Any idea how I can get DS-5 to properly handle local variables?
>
>
> I'm trying to convert an old-style board config to a device tree,
> and I can't even get serial to work... :-(
>
> Regards.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




-- 
Thanks,
with regards,
Suman Tripathi

arch/arm/kernel/setup.c does not compile at -O0

[Russell King - ARM Linux]

On Thu, Jul 30, 2015 at 08:53:45PM +0530, Suman Tripathi wrote:
> Hi,
> 
> On Thu, Jul 30, 2015 at 6:23 PM, Mason <slash.tmp@free.fr> wrote:
> >
> > Hello everyone,
> >
> > I'm trying to debug a live kernel (v3.14) using a DS-5 JTAG probe.
> >
> > In order to make the control flow easier to follow, I disabled
> > optimizations by adding
> >
> >   subdir-ccflags-y := -O0
> >
> > to arch/arm/kernel/Makefile
> >
> > With that change, linking fails:
> >
> > arch/arm/kernel/setup.c:924: undefined reference to `psci_smp_ops'
> >
> >       if (psci_smp_available())
> >         smp_set_ops(&psci_smp_ops);
> >
> > #ifdef CONFIG_ARM_PSCI
> > void psci_init(void);
> > bool psci_smp_available(void);
> > #else
> > static inline void psci_init(void) { }
> > static inline bool psci_smp_available(void) { return false; }
> > #endif
> >
> > The optimizer is able to remove the entire block, but this
> > does not happen when optimizations are disabled.
> >
> > Is compiling at -O0 not supported?
> 
> If you have inline functions, it won't compile at -O0

That's incorrect.

If you have static inline functions, there isn't a problem irrespective
of optimisation level - they'll become merely static functions which
won't be inlined, and you'll end up with a copy of the function per
compilation unit.

If you have extern inline functions, they also won't be inlined, but
unlike static inline, the compiler won't emit a static function.
Instead, the compiler expects the function to be provided via another
compilation unit or library (which won't happen in the Linux kernel.)
However, Linux kernel coding style does not allow the use of extern
inline functions.

The problem which the Linux kernel has is that we rely on the compiler
performing optimisations in multiple places - such as eliminating code
which can't be reached.  Disabling the optimiser prevents such
eliminations from happening, and ends up leaving symbols behind which
are purposely not-defined (which are so in order to detect errors for
accessors like get_user(), etc. which are only defined to operate on
1, 2, 4 and maybe 8 byte values.)

For example:

#define __put_user_check(x, p)                                          \
        ({                                                              \
                unsigned long __limit = current_thread_info()->addr_limit - 1; \                const typeof(*(p)) __user *__tmp_p = (p);               \
                register const typeof(*(p)) __r2 asm("r2") = (x);       \
                register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
                register unsigned long __l asm("r1") = __limit;         \
                register int __e asm("r0");                             \
                switch (sizeof(*(__p))) {                               \
                case 1:                                                 \
                        __put_user_x(__r2, __p, __e, __l, 1);           \
                        break;                                          \
                case 2:                                                 \
                        __put_user_x(__r2, __p, __e, __l, 2);           \
                        break;                                          \
                case 4:                                                 \
                        __put_user_x(__r2, __p, __e, __l, 4);           \
                        break;                                          \
                case 8:                                                 \
                        __put_user_x(__r2, __p, __e, __l, 8);           \
                        break;                                          \
                default: __e = __put_user_bad(); break;                 \
                }                                                       \
                __e;                                                    \
        })

which relies on the optimiser removing all the cases which don't apply to
the access size.  Disabling optimisation prevents that happening, so you
end up with the entire switch() statement coded in the output assembly
for every invocation of this macro - which includes a call to
__put_user_bad() just in case sizeof(*__p) changes unexpectedly.

Building the kernel with optimisation disabled is not supported.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

arch/arm/kernel/setup.c does not compile at -O0

[Suman Tripathi]

On Thu, Jul 30, 2015 at 9:20 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jul 30, 2015 at 08:53:45PM +0530, Suman Tripathi wrote:
>> Hi,
>>
>> On Thu, Jul 30, 2015 at 6:23 PM, Mason <slash.tmp@free.fr> wrote:
>> >
>> > Hello everyone,
>> >
>> > I'm trying to debug a live kernel (v3.14) using a DS-5 JTAG probe.
>> >
>> > In order to make the control flow easier to follow, I disabled
>> > optimizations by adding
>> >
>> >   subdir-ccflags-y := -O0
>> >
>> > to arch/arm/kernel/Makefile
>> >
>> > With that change, linking fails:
>> >
>> > arch/arm/kernel/setup.c:924: undefined reference to `psci_smp_ops'
>> >
>> >       if (psci_smp_available())
>> >         smp_set_ops(&psci_smp_ops);
>> >
>> > #ifdef CONFIG_ARM_PSCI
>> > void psci_init(void);
>> > bool psci_smp_available(void);
>> > #else
>> > static inline void psci_init(void) { }
>> > static inline bool psci_smp_available(void) { return false; }
>> > #endif
>> >
>> > The optimizer is able to remove the entire block, but this
>> > does not happen when optimizations are disabled.
>> >
>> > Is compiling at -O0 not supported?
>>
>> If you have inline functions, it won't compile at -O0
>
> That's incorrect.
>
> If you have static inline functions, there isn't a problem irrespective
> of optimisation level - they'll become merely static functions which
> won't be inlined, and you'll end up with a copy of the function per
> compilation unit.
>
> If you have extern inline functions, they also won't be inlined, but
> unlike static inline, the compiler won't emit a static function.
> Instead, the compiler expects the function to be provided via another
> compilation unit or library (which won't happen in the Linux kernel.)
> However, Linux kernel coding style does not allow the use of extern
> inline functions.
>
> The problem which the Linux kernel has is that we rely on the compiler
> performing optimisations in multiple places - such as eliminating code
> which can't be reached.  Disabling the optimiser prevents such
> eliminations from happening, and ends up leaving symbols behind which
> are purposely not-defined (which are so in order to detect errors for
> accessors like get_user(), etc. which are only defined to operate on
> 1, 2, 4 and maybe 8 byte values.)
>
> For example:
>
> #define __put_user_check(x, p)                                          \
>         ({                                                              \
>                 unsigned long __limit = current_thread_info()->addr_limit - 1; \                const typeof(*(p)) __user *__tmp_p = (p);               \
>                 register const typeof(*(p)) __r2 asm("r2") = (x);       \
>                 register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
>                 register unsigned long __l asm("r1") = __limit;         \
>                 register int __e asm("r0");                             \
>                 switch (sizeof(*(__p))) {                               \
>                 case 1:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 1);           \
>                         break;                                          \
>                 case 2:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 2);           \
>                         break;                                          \
>                 case 4:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 4);           \
>                         break;                                          \
>                 case 8:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 8);           \
>                         break;                                          \
>                 default: __e = __put_user_bad(); break;                 \
>                 }                                                       \
>                 __e;                                                    \
>         })
>
> which relies on the optimiser removing all the cases which don't apply to
> the access size.  Disabling optimisation prevents that happening, so you
> end up with the entire switch() statement coded in the output assembly
> for every invocation of this macro - which includes a call to
> __put_user_bad() just in case sizeof(*__p) changes unexpectedly.
>
> Building the kernel with optimisation disabled is not supported.

Thanks for the info Russell !!

>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Thanks,
with regards,
Suman Tripathi

arch/arm/kernel/setup.c does not compile at -O0

[Suman Tripathi]

Hi Russell,

On Thu, Jul 30, 2015 at 9:20 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jul 30, 2015 at 08:53:45PM +0530, Suman Tripathi wrote:
>> Hi,
>>
>> On Thu, Jul 30, 2015 at 6:23 PM, Mason <slash.tmp@free.fr> wrote:
>> >
>> > Hello everyone,
>> >
>> > I'm trying to debug a live kernel (v3.14) using a DS-5 JTAG probe.
>> >
>> > In order to make the control flow easier to follow, I disabled
>> > optimizations by adding
>> >
>> >   subdir-ccflags-y := -O0
>> >
>> > to arch/arm/kernel/Makefile
>> >
>> > With that change, linking fails:
>> >
>> > arch/arm/kernel/setup.c:924: undefined reference to `psci_smp_ops'
>> >
>> >       if (psci_smp_available())
>> >         smp_set_ops(&psci_smp_ops);
>> >
>> > #ifdef CONFIG_ARM_PSCI
>> > void psci_init(void);
>> > bool psci_smp_available(void);
>> > #else
>> > static inline void psci_init(void) { }
>> > static inline bool psci_smp_available(void) { return false; }
>> > #endif
>> >
>> > The optimizer is able to remove the entire block, but this
>> > does not happen when optimizations are disabled.
>> >
>> > Is compiling at -O0 not supported?
>>
>> If you have inline functions, it won't compile at -O0
>
> That's incorrect.
>
> If you have static inline functions, there isn't a problem irrespective
> of optimisation level - they'll become merely static functions which
> won't be inlined, and you'll end up with a copy of the function per
> compilation unit.
>
> If you have extern inline functions, they also won't be inlined, but
> unlike static inline, the compiler won't emit a static function.
> Instead, the compiler expects the function to be provided via another
> compilation unit or library (which won't happen in the Linux kernel.)
> However, Linux kernel coding style does not allow the use of extern
> inline functions.
>
> The problem which the Linux kernel has is that we rely on the compiler
> performing optimisations in multiple places - such as eliminating code
> which can't be reached.  Disabling the optimiser prevents such
> eliminations from happening, and ends up leaving symbols behind which
> are purposely not-defined (which are so in order to detect errors for
> accessors like get_user(), etc. which are only defined to operate on
> 1, 2, 4 and maybe 8 byte values.)
>
> For example:
>
> #define __put_user_check(x, p)                                          \
>         ({                                                              \
>                 unsigned long __limit = current_thread_info()->addr_limit - 1; \                const typeof(*(p)) __user *__tmp_p = (p);               \
>                 register const typeof(*(p)) __r2 asm("r2") = (x);       \
>                 register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
>                 register unsigned long __l asm("r1") = __limit;         \
>                 register int __e asm("r0");                             \
>                 switch (sizeof(*(__p))) {                               \
>                 case 1:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 1);           \
>                         break;                                          \
>                 case 2:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 2);           \
>                         break;                                          \
>                 case 4:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 4);           \
>                         break;                                          \
>                 case 8:                                                 \
>                         __put_user_x(__r2, __p, __e, __l, 8);           \
>                         break;                                          \
>                 default: __e = __put_user_bad(); break;                 \
>                 }                                                       \
>                 __e;                                                    \
>         })
>
> which relies on the optimiser removing all the cases which don't apply to
> the access size.  Disabling optimisation prevents that happening, so you
> end up with the entire switch() statement coded in the output assembly
> for every invocation of this macro - which includes a call to
> __put_user_bad() just in case sizeof(*__p) changes unexpectedly.
>
> Building the kernel with optimisation disabled is not supported.

After some analysis found that :

1. with -O0 compiletime assertion's kick off and results in build failures

2. with -O1 or more it's doesn't kick off.

why this is so ?

For example below , the smp_store_release kicks calls
compiletime_assert_atomic_type  and build fails at O0 but passes at O1
.Point is this happens at preprocessing stage and cases for size of *p
afterwards which can be optimized when optimiser is enabled.

Snippet of smp_store_release :

#define smp_store_release(p, v) \
do { \
compiletime_assert_atomic_type(*p); \
switch (sizeof(*p)) { \
case 1: \
asm volatile ("stlrb %w1, %0" \
: "=Q" (*p) : "r" (v) : "memory"); \
break; \
case 2: \
asm volatile ("stlrh %w1, %0" \
: "=Q" (*p) : "r" (v) : "memory"); \
break; \
case 4: \
asm volatile ("stlr %w1, %0" \
: "=Q" (*p) : "r" (v) : "memory"); \
break; \
case 8: \
asm volatile ("stlr %1, %0" \
: "=Q" (*p) : "r" (v) : "memory"); \
break; \
} \
} while (0)

build output :

/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/arch/arm64/kvm/../../../virt/kvm/kvm_main.c:
In function \u2018kvm_io_bus_register_dev\u2019:
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/include/linux/compiler.h:429:38:
error: call to \u2018__compiletime_assert_3113\u2019 declared with
attribute error: Need native word sized stores/loads for atomicity.
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/include/linux/compiler.h:412:4:
note: in definition of macro \u2018__compiletime_assert\u2019
    prefix ## suffix();    \
    ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/include/linux/compiler.h:429:2:
note: in expansion of macro \u2018_compiletime_assert\u2019
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/include/linux/compiler.h:432:2:
note: in expansion of macro \u2018compiletime_assert\u2019
  compiletime_assert(__native_word(t),    \
  ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/arch/arm64/include/asm/barrier.h:66:2:
note: in expansion of macro \u2018compiletime_assert_atomic_type\u2019
  compiletime_assert_atomic_type(*p);    \
  ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/include/linux/rcupdate.h:698:34:
note: in expansion of macro \u2018smp_store_release\u2019
 #define rcu_assign_pointer(p, v) smp_store_release(&p, RCU_INITIALIZER(v))
                                  ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3113:2:
note: in expansion of macro \u2018rcu_assign_pointer\u2019
  rcu_assign_pointer(kvm->buses[bus_idx], new_bus);
  ^
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/arch/arm64/kvm/../../../virt/kvm/kvm_main.c:
In function \u2018kvm_io_bus_unregister_dev\u2019:
/projects/pnq/P4sbSW/stripath/open_source_sata/processor/shadowcat/linux/include/linux/compiler.h:429:38:
error: call to \u2018__compiletime_assert_3148\u2019 declared with
attribute error: Need native word sized stores/loads for atomicity.
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^


>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Thanks,
with regards,
Suman Tripathi