search

foss-for-synopsys-dwc-arc-processors / buildroot

The development tree for Buildroot support for the Synopsys DesignWare ARC processor family
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-dev/README.md
Other
7 stars 2 forks source link

ARC: add -z max-page-size option to the TARGET_LDFLAGS #36

Closed pavelvkozlov closed 1 year ago

pavelvkozlov commented 1 year ago

Explicitly add linker option -z max-page-size to the _TARGETLDFLAGS. Fix the problem with incorrect segments alignment for some libraries(libstdc++) in systems with 16K,64K page size.

abrodkin commented 10 months ago

@pavelvkozlov so that's funny, with that patch alone I don't see any differences in libstdc++.so build. For example, for ARC HS58 it gets sections aligned by 4KiB:

$ ./output/host/bin/arc32-linux-readelf -l ./output/build/host-gcc-final-arc-2023.09-release/build/arc32-buildroot-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.32

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x1ade4d 0x1ade4d R E 0x2000
  LOAD           0x1aea50 0x001aea50 0x001aea50 0x07414 0x09e70 RW  0x2000
  DYNAMIC        0x1b3790 0x001b3790 0x001b3790 0x00108 0x00108 RW  0x4
  TLS            0x1aea50 0x001aea50 0x001aea50 0x00000 0x00010 R   0x4
  GNU_EH_FRAME   0x161460 0x00161460 0x00161460 0x09f8c 0x09f8c R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0x1aea50 0x001aea50 0x001aea50 0x055b0 0x055b0 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .plt .text .rodata .eh_frame_hdr .eh_frame .gcc_except_table
   01     .init_array .fini_array .data.rel.ro .dynamic .got .got.plt .data .bss
   02     .dynamic
   03     .tbss
   04     .eh_frame_hdr
   05
   06     .init_array .fini_array .data.rel.ro .dynamic .got

and that makes sense because TARGET_LDFLAGS are not used as opposed to existing handling of TARGET_CFLAGS & TARGET_CXXFLAGS on GCC configuration, see https://github.com/buildroot/buildroot/blob/master/package/gcc/gcc.mk#L101-L117:

GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS)
GCC_COMMON_TARGET_CXXFLAGS = $(TARGET_CXXFLAGS)

...

# Propagate options used for target software building to GCC target libs
HOST_GCC_COMMON_CONF_ENV += CFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CFLAGS)"
HOST_GCC_COMMON_CONF_ENV += CXXFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CXXFLAGS)"

And so for the proposed change to make a difference we need to forward LDFLAGS to libstdc++ configuration similarly to CFLAGS & CXXFLAGS that way:

diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index 93bc46643c..d9a2164c74 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -100,6 +100,7 @@ HOST_GCC_COMMON_MAKE_OPTS = \

 GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS)
 GCC_COMMON_TARGET_CXXFLAGS = $(TARGET_CXXFLAGS)
+GCC_COMMON_TARGET_LDFLAGS = $(TARGET_LDFLAGS)

 # used to fix ../../../../libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 ifeq ($(BR2_ENABLE_DEBUG),y)
@@ -115,6 +116,7 @@ endif
 # Propagate options used for target software building to GCC target libs
 HOST_GCC_COMMON_CONF_ENV += CFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CFLAGS)"
 HOST_GCC_COMMON_CONF_ENV += CXXFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CXXFLAGS)"
+HOST_GCC_COMMON_CONF_ENV += LDFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_LDFLAGS)"
 HOST_GCC_COMMON_CONF_ENV += AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib

 # libitm needs sparc V9+

And with that, indeed I see how nicely sections are aligned by 4 KiB in libstdc++.so:

$ ./output/host/bin/arc32-linux-readelf -l ./output/build/host-gcc-final-arc-2023.09-release/build/arc32-buildroot-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.32

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x1ade4d 0x1ade4d R E 0x1000
  LOAD           0x1aea50 0x001aea50 0x001aea50 0x07414 0x09e70 RW  0x1000
  DYNAMIC        0x1b3790 0x001b3790 0x001b3790 0x00108 0x00108 RW  0x4
  TLS            0x1aea50 0x001aea50 0x001aea50 0x00000 0x00010 R   0x4
  GNU_EH_FRAME   0x161460 0x00161460 0x00161460 0x09f8c 0x09f8c R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0x1aea50 0x001aea50 0x001aea50 0x055b0 0x055b0 R   0x1

And so, my question to you is if I'm missing something of that change in package/gcc/gcc.mk somehow slipped through the cracks and we need to add it now?