Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules

Started by William Cohen on Jan 22, 2016 · 7 messages from 3 authors · Last reply Jan 22, 2016

Subsystems (2)

Maintainers (3)

STALE3941d

open the first message on its own page

  1. [PATCH] Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
    Related patches
  2. [PATCH] Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
    Related patches
  3. [PATCH] Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
    Related patches
  4. [PATCH] Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
    Related patches
  5. [PATCH] Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
    Related patches
  6. [PATCH] Eliminate the .eh_frame sections from the aarch64 vmlinux and kernel modules
    Related patches

William Cohen

Message details and related content
Open message details and related content
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.

Signed-off-by: William Cohen <redacted>
---
 arch/arm64/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index cd822d8..094a137 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -27,6 +27,7 @@ $(warning LSE atomics not supported by binutils)
 endif
 
 KBUILD_CFLAGS	+= -mgeneral-regs-only $(lseinstr)
+KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
 KBUILD_AFLAGS	+= $(lseinstr)
 
 ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
-- 
2.5.0

Ard Biesheuvel replied to William Cohen

Message details and related content
Open message details and related content
On 22 January 2016 at 04:56, William Cohen [off-list ref] wrote:
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.
With my GCC-4.9.3 Linaro toolchain, I am not getting .eh_frame
sections only .debug_frame sections. The patch still makes sense imo,
but it appears to be redundant in some cases, and it would be useful
to figure out why. Which toolchain have you tested this with?
quoted hunk
Signed-off-by: William Cohen <redacted>
---
 arch/arm64/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index cd822d8..094a137 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -27,6 +27,7 @@ $(warning LSE atomics not supported by binutils)
 endif

 KBUILD_CFLAGS  += -mgeneral-regs-only $(lseinstr)
+KBUILD_CFLAGS  += -fno-asynchronous-unwind-tables
 KBUILD_AFLAGS  += $(lseinstr)

 ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
--
2.5.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

William Cohen replied to Ard Biesheuvel

Message details and related content
Open message details and related content
On 01/22/2016 02:41 AM, Ard Biesheuvel wrote:
On 22 January 2016 at 04:56, William Cohen [off-list ref] wrote:
quoted
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.
With my GCC-4.9.3 Linaro toolchain, I am not getting .eh_frame
sections only .debug_frame sections. The patch still makes sense imo,
but it appears to be redundant in some cases, and it would be useful
to figure out why. Which toolchain have you tested this with?
Hi,

I have observed the .eh_frame being generated with gcc-5.3.1 that is in Fedora 23.

-Will

quoted
Signed-off-by: William Cohen <redacted>
---
 arch/arm64/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index cd822d8..094a137 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -27,6 +27,7 @@ $(warning LSE atomics not supported by binutils)
 endif

 KBUILD_CFLAGS  += -mgeneral-regs-only $(lseinstr)
+KBUILD_CFLAGS  += -fno-asynchronous-unwind-tables
 KBUILD_AFLAGS  += $(lseinstr)

 ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
--
2.5.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel





  

    

      
      Mark Rutland      replied to William Cohen      
      
    

  

  

    Message details and related content
    
Open message details and related content

  

  
On Fri, Jan 22, 2016 at 09:43:25AM -0500, William Cohen wrote:
On 01/22/2016 02:41 AM, Ard Biesheuvel wrote:
quoted
On 22 January 2016 at 04:56, William Cohen [off-list ref] wrote:
quoted
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.
With my GCC-4.9.3 Linaro toolchain, I am not getting .eh_frame
sections only .debug_frame sections. The patch still makes sense imo,
but it appears to be redundant in some cases, and it would be useful
to figure out why. Which toolchain have you tested this with?
Hi,

I have observed the .eh_frame being generated with gcc-5.3.1 that is in Fedora 23.
FWIW, I do not see this with the Linaro 15.08 GCC 5.1.1.

It would be interesting to know if that's something that changed
upstream between 5.1.x and 5.3.x or if that's a Fedora-specific
configuration option, but either way the patch seems reasonable.

Thanks,
Mark.





  

    

      
      William Cohen      replied to Mark Rutland      
      
    

  

  

    Message details and related content
    
Open message details and related content

  

  
On 01/22/2016 10:02 AM, Mark Rutland wrote:
On Fri, Jan 22, 2016 at 09:43:25AM -0500, William Cohen wrote:
quoted
On 01/22/2016 02:41 AM, Ard Biesheuvel wrote:
quoted
On 22 January 2016 at 04:56, William Cohen [off-list ref] wrote:
quoted
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.
With my GCC-4.9.3 Linaro toolchain, I am not getting .eh_frame
sections only .debug_frame sections. The patch still makes sense imo,
but it appears to be redundant in some cases, and it would be useful
to figure out why. Which toolchain have you tested this with?
Hi,

I have observed the .eh_frame being generated with gcc-5.3.1 that is in Fedora 23.
FWIW, I do not see this with the Linaro 15.08 GCC 5.1.1.

It would be interesting to know if that's something that changed
upstream between 5.1.x and 5.3.x or if that's a Fedora-specific
configuration option, but either way the patch seems reasonable.

Thanks,
Mark.
Hi Mark,

The sizes of the resulting vmlinux files are pretty similar. However, I could see the change in available memory when I booted the kernels. To see the change without booting you need to use eu-readelf.  The vmlinux.eh_frame is the original build and the vmlinux.no_eh_frame is the build with the -fno-asynchronous-unwind-tables.  The "LOAD" line of "eu-readelf -l" show MemSiz drop.  The "ue-readelf -S" output shows movement of the data moved from the .eh_frame to the .debug_frame section.  Below is the various eu-readelf output.

-Will

[linaro at localhost kernel]$ eu-readelf -l vmlinux.eh_frame 
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x010000 0xffffffc000080000 0xffffffc000080000 0xe33800 0x1b2a648 RWE 0x10000
  NOTE           0xd04a00 0xffffffc000d74a00 0xffffffc000d74a00 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      .head.text .text .text.init .rodata .eh_frame .init.rodata.str1.8 .init.eh_frame __bug_table .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .init.text .exit.text .init.data .data..percpu .altinstructions .altinstr_replacement .data .pecoff_edata_padding .bss
   01      .notes
   02     
[linaro at localhost kernel]$ eu-readelf -l vmlinux.no_eh_frame 
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x010000 0xffffffc000080000 0xffffffc000080000 0xc83800 0x197a648 RWE 0x10000
  NOTE           0xb53a00 0xffffffc000bc3a00 0xffffffc000bc3a00 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      .head.text .text .text.init .rodata .init.rodata.str1.8 __bug_table .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .init.text .exit.text .init.data .data..percpu .altinstructions .altinstr_replacement .data .pecoff_edata_padding .bss
   01      .notes
   02     

[linaro at localhost kernel]$ eu-readelf -S vmlinux.eh_frame 
There are 37 section headers, starting at offset 0x8b07650:

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
[ 0]                      NULL         0000000000000000 00000000 00000000  0        0   0  0
[ 1] .head.text           PROGBITS     ffffffc000080000 00010000 00002000  0 AX     0   0 4096
[ 2] .text                PROGBITS     ffffffc000082000 00012000 00807890  0 AX     0   0 4096
77 more lines





  

    

      
      Mark Rutland      replied to William Cohen      
      
    

  

  

    Message details and related content
    
Open message details and related content

  

  
On Fri, Jan 22, 2016 at 10:36:12AM -0500, William Cohen wrote:
On 01/22/2016 10:02 AM, Mark Rutland wrote:
quoted
On Fri, Jan 22, 2016 at 09:43:25AM -0500, William Cohen wrote:
quoted
On 01/22/2016 02:41 AM, Ard Biesheuvel wrote:
quoted
On 22 January 2016 at 04:56, William Cohen [off-list ref] wrote:
quoted
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.
With my GCC-4.9.3 Linaro toolchain, I am not getting .eh_frame
sections only .debug_frame sections. The patch still makes sense imo,
but it appears to be redundant in some cases, and it would be useful
to figure out why. Which toolchain have you tested this with?
Hi,

I have observed the .eh_frame being generated with gcc-5.3.1 that is in Fedora 23.
FWIW, I do not see this with the Linaro 15.08 GCC 5.1.1.

It would be interesting to know if that's something that changed
upstream between 5.1.x and 5.3.x or if that's a Fedora-specific
configuration option, but either way the patch seems reasonable.

Thanks,
Mark.
Hi Mark,

The sizes of the resulting vmlinux files are pretty similar. However,
I could see the change in available memory when I booted the kernels.
To see the change without booting you need to use eu-readelf.
I was looking with the binutils readelf form the Linaro 15.08 toolchain.
Will that not show eh_frame for some reason?

Regardless, as I mentioned the patch seems fine regardless, the details
were mostly interesting for the commit message and curiosity.

The vmlinux.eh_frame is the original build and the vmlinux.no_eh_frame
is the build with the -fno-asynchronous-unwind-tables.  The "LOAD"
line of "eu-readelf -l" show MemSiz drop.  The "ue-readelf -S" output
shows movement of the data moved from the .eh_frame to the
.debug_frame section.  Below is the various eu-readelf output.
Thanks for the info.

Mark.

-Will

[linaro at localhost kernel]$ eu-readelf -l vmlinux.eh_frame 
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x010000 0xffffffc000080000 0xffffffc000080000 0xe33800 0x1b2a648 RWE 0x10000
  NOTE           0xd04a00 0xffffffc000d74a00 0xffffffc000d74a00 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      .head.text .text .text.init .rodata .eh_frame .init.rodata.str1.8 .init.eh_frame __bug_table .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .init.text .exit.text .init.data .data..percpu .altinstructions .altinstr_replacement .data .pecoff_edata_padding .bss
   01      .notes
   02     
[linaro at localhost kernel]$ eu-readelf -l vmlinux.no_eh_frame 
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x010000 0xffffffc000080000 0xffffffc000080000 0xc83800 0x197a648 RWE 0x10000
  NOTE           0xb53a00 0xffffffc000bc3a00 0xffffffc000bc3a00 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      .head.text .text .text.init .rodata .init.rodata.str1.8 __bug_table .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .init.text .exit.text .init.data .data..percpu .altinstructions .altinstr_replacement .data .pecoff_edata_padding .bss
   01      .notes
   02     

[linaro at localhost kernel]$ eu-readelf -S vmlinux.eh_frame 
There are 37 section headers, starting at offset 0x8b07650:

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
[ 0]                      NULL         0000000000000000 00000000 00000000  0        0   0  0
[ 1] .head.text           PROGBITS     ffffffc000080000 00010000 00002000  0 AX     0   0 4096
[ 2] .text                PROGBITS     ffffffc000082000 00012000 00807890  0 AX     0   0 4096
[ 3] .text.init           PROGBITS     ffffffc000889890 00819890 00000090  0 AX     0   0 16
[ 4] .rodata              PROGBITS     ffffffc00088a000 0081a000 002d22a0  0 A      0   0 4096
[ 5] .eh_frame            PROGBITS     ffffffc000b5c2a0 00aec2a0 001b0960  0 A      0   0  8
[ 6] .init.rodata.str1.8  PROGBITS     ffffffc000d0cc00 00c9cc00 00000768  1 AMS    0   0  8
81 more quoted lines





  

    

      
      William Cohen      replied to Mark Rutland      
      
    

  

  

    Message details and related content
    
Open message details and related content

  

  
On 01/22/2016 12:02 PM, Mark Rutland wrote:
On Fri, Jan 22, 2016 at 10:36:12AM -0500, William Cohen wrote:
quoted
On 01/22/2016 10:02 AM, Mark Rutland wrote:
quoted
On Fri, Jan 22, 2016 at 09:43:25AM -0500, William Cohen wrote:
quoted
On 01/22/2016 02:41 AM, Ard Biesheuvel wrote:
quoted
On 22 January 2016 at 04:56, William Cohen [off-list ref] wrote:
quoted
By default the aarch64 gcc generates .eh_frame sections.  Unlike
.debug_frame sections, the .eh_frame sections are loaded into memory
when the associated code is loaded.  On an example kernel being built
with this default the .eh_frame section in vmlinux used an extra 1.7MB
of memory.  The x86 disables the creation of the .eh_frame section.
The aarch64 should probably do the same to save some memory.
With my GCC-4.9.3 Linaro toolchain, I am not getting .eh_frame
sections only .debug_frame sections. The patch still makes sense imo,
but it appears to be redundant in some cases, and it would be useful
to figure out why. Which toolchain have you tested this with?
Hi,

I have observed the .eh_frame being generated with gcc-5.3.1 that is in Fedora 23.
FWIW, I do not see this with the Linaro 15.08 GCC 5.1.1.

It would be interesting to know if that's something that changed
upstream between 5.1.x and 5.3.x or if that's a Fedora-specific
configuration option, but either way the patch seems reasonable.

Thanks,
Mark.
Hi Mark,

The sizes of the resulting vmlinux files are pretty similar. However,
I could see the change in available memory when I booted the kernels.
To see the change without booting you need to use eu-readelf.
I was looking with the binutils readelf form the Linaro 15.08 toolchain.
Will that not show eh_frame for some reason?
Hi Mark,

eu-readelf was used because it was handy. On fedora 23 the binutils readelf gives similar information. I would expect it to do the same for the Linaro 15.08 toolchain.

Regardless, as I mentioned the patch seems fine regardless, the details
were mostly interesting for the commit message and curiosity.
Looking through the fedora gcc srpm I did find a patch that turns on the asynchronouns_unwind_tables by default, gcc5-aarch64-async-unw-tables.patch. The history of checkins for Fedora gcc srpm shows it was added 2014-07-16.  However, I don't see it in the upstream gcc. That would explain the difference in behavior between Fedora and Linaro.  The patch itself turns on eh_frame support so that exception handling still works for user-space code even when frame pointers are disabled.

-Will
quoted
The vmlinux.eh_frame is the original build and the vmlinux.no_eh_frame
is the build with the -fno-asynchronous-unwind-tables.  The "LOAD"
line of "eu-readelf -l" show MemSiz drop.  The "ue-readelf -S" output
shows movement of the data moved from the .eh_frame to the
.debug_frame section.  Below is the various eu-readelf output.
Thanks for the info.

Mark.

quoted
-Will

[linaro at localhost kernel]$ eu-readelf -l vmlinux.eh_frame 
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x010000 0xffffffc000080000 0xffffffc000080000 0xe33800 0x1b2a648 RWE 0x10000
  NOTE           0xd04a00 0xffffffc000d74a00 0xffffffc000d74a00 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      .head.text .text .text.init .rodata .eh_frame .init.rodata.str1.8 .init.eh_frame __bug_table .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .init.text .exit.text .init.data .data..percpu .altinstructions .altinstr_replacement .data .pecoff_edata_padding .bss
   01      .notes
   02     
[linaro at localhost kernel]$ eu-readelf -l vmlinux.no_eh_frame 
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x010000 0xffffffc000080000 0xffffffc000080000 0xc83800 0x197a648 RWE 0x10000
  NOTE           0xb53a00 0xffffffc000bc3a00 0xffffffc000bc3a00 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00      .head.text .text .text.init .rodata .init.rodata.str1.8 __bug_table .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .init.text .exit.text .init.data .data..percpu .altinstructions .altinstr_replacement .data .pecoff_edata_padding .bss
   01      .notes
   02     

[linaro at localhost kernel]$ eu-readelf -S vmlinux.eh_frame 
92 more quoted lines










    
  

  
    

      

        Keyboard shortcuts
      

      

        
          
hback out one level

          
jnext message in thread / next series-diff position

          
kprevious message in thread / previous series-diff position

          
ldrill in

          
Escclose help / fold thread tree

          
?toggle this help