Re: CREL relocation format for ELF

2024-03-29 Thread Fangrui Song via Gcc
On Thu, Mar 28, 2024 at 2:23 AM Jan Beulich wrote: > > On 28.03.2024 08:43, Fangrui Song wrote: > > On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote: > >> > >> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote: > >>> > >>> The relocation formats REL and RELA for ELF are inefficient. In a > >>

Re: CREL relocation format for ELF (was: RELLEB)

2024-03-28 Thread Fangrui Song via Gcc
On Thu, Mar 28, 2024 at 6:04 AM Alan Modra wrote: > > On Fri, Mar 22, 2024 at 06:51:41PM -0700, Fangrui Song wrote: > > On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote: > > > I propose RELLEB, a new format offering significant file size > > > reductions: 17.2% (x86-64), 16.5% (aarch64), and ev

Re: CREL relocation format for ELF (was: RELLEB)

2024-03-28 Thread Fangrui Song via Gcc
On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote: > > On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote: > > > > The relocation formats REL and RELA for ELF are inefficient. In a > > release build of Clang for x86-64, .rela.* sections consume a > > significant portion (approximately 20.9%) of

CREL relocation format for ELF (was: RELLEB)

2024-03-22 Thread Fangrui Song via Gcc
On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote: > > The relocation formats REL and RELA for ELF are inefficient. In a > release build of Clang for x86-64, .rela.* sections consume a > significant portion (approximately 20.9%) of the file size. > > I propose RELLEB, a new format offering signif

RELLEB relocation format for ELF

2024-03-14 Thread Fangrui Song via Gcc
The relocation formats REL and RELA for ELF are inefficient. In a release build of Clang for x86-64, .rela.* sections consume a significant portion (approximately 20.9%) of the file size. I propose RELLEB, a new format offering significant file size reductions: 17.2% (x86-64), 16.5% (aarch64), and

Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED

2021-06-18 Thread Fangrui Song via Gcc
On 2021-06-18, H.J. Lu via llvm-dev wrote: Add GNU_PROPERTY_1_NEEDED: #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO to indicate the needed properties by the object file. I am fine with this logical OR style usage. But see below, do we need it for ld.so runtime check? (As I me

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

2021-06-17 Thread Fangrui Song via Gcc
On 2021-06-17, H.J. Lu via llvm-dev wrote: On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > #define GNU_PROPERTY_UINT32_AND_LO 0xb000 > #define GNU_PROPERTY_UINT32_AND_HI 0xb00

Re: Future debug options: -f* or -g*?

2020-07-09 Thread Fangrui Song via Gcc
Fix email addresses:) On 2020-07-09, Fangrui Song wrote: Both GCC and Clang have implemented many debugging options under -f and -g. Whether options go to -f or -g appears to be pretty arbitrary decisions. A non-complete list of GCC supported debug options is documented here at https://gcc.gnu.

Future debug options: -f* or -g*?

2020-07-09 Thread Fangrui Song via Gcc
Both GCC and Clang have implemented many debugging options under -f and -g. Whether options go to -f or -g appears to be pretty arbitrary decisions. A non-complete list of GCC supported debug options is documented here at https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html I think there op