Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB-Alt <bohannonindustriesllc@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Thu, 6 Jun 2024 15:38:21 -0500
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <v3t6nu$1liet$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <v38of2$1gsj2$1@dont-email.me>
 <v39v87$1n7bk$1@dont-email.me> <20240530170836.00005fa0@yahoo.com>
 <v3a3k5$1ntrn$1@dont-email.me> <20240530180345.00003d9f@yahoo.com>
 <v3chc4$27uij$1@dont-email.me> <20240531161937.000063af@yahoo.com>
 <20240531162811.00006719@yahoo.com> <20240531164835.00007128@yahoo.com>
 <v3cldt$28n91$2@dont-email.me> <20240531173437.00003bee@yahoo.com>
 <v3d3ct$2b5sl$1@dont-email.me> <v3d97c$2c6ea$1@dont-email.me>
 <22r6O.5934$xPJ1.2590@fx09.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 06 Jun 2024 22:38:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a54bed4e555a8227e5e1197e18589540";
	logging-data="1755613"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18vuUnFXrnc0nRjwyrUQuvXMzKolgvzAlc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VQsERSaRCopf6lHiK1Gn+7SrtDM=
Content-Language: en-US
In-Reply-To: <22r6O.5934$xPJ1.2590@fx09.iad>
Bytes: 5645

On 5/31/2024 4:11 PM, Scott Lurndal wrote:
> jak <nospam@please.ty> writes:
>> bart ha scritto:
>>> On 31/05/2024 15:34, Michael S wrote:
>>>> On Fri, 31 May 2024 15:04:46 +0100
>>>> bart <bc@freeuk.com> wrote:
>>>
>>
> 
>   <snip>
> 
>>>
>>> Instead of one compiler, here I used two compilers, a tool 'objcopy'
>>> (which bizarrely needs to generate ELF format files) and lots of extra
>>> ugly code. I also need to disregard whatever the hell _binary_..._size
>>> does.
>>>
>>> But it works.
>>>
>>>
>>>
>> You could use the pe-x86-64 format instead of the elf64-x86-64 to reduce
>> the size of the object.
> 
> By a half dozen bytes, perhaps, and only if your binutils have been
> built to support pe-x86-64:
> 
> $ objcopy -I binary -O pe-x86-64 main.cpp /tmp/test1.o
> objcopy:/tmp/test1.o: Invalid bfd target
> 
> The ELF64 format has a 64 byte header, the string table and the
> symbol table, and the remainder is the binary
> data.  The PE header may save a few bytes by using 32-bit fields in
> the PE COFF header and symbol table.
> 
> Note, you might want to trim your posts when replying with a one-sentence reply.
> 

While I can't say much for using objcopy here (it is likely to be 
hindered by however the program was compiled and linked, in any case), 
in some other contexts PE/COFF can save more significant amounts of 
space vs ELF.


In particular:

PE/COFF typically only stores symbols for imports and exports, rather 
than for every symbol in the binary (though, IIRC, GCC+LD does tend to 
generate PE/COFF output with every symbol present, *1, so this advantage 
is mostly N/A if using GCC).


*1: Namely, it does not seem to treat imports/exports separately from 
normal "extern" symbols, so when compiling a DLL will tend to export 
every symbol in the DLL (and will implicitly import any symbol when 
linking against this DLL, rather than requiring either a line in a 
".DEF" file or the use of "__declspec(dllimport)" or similar on 
prototypes/variables to declare that they are being imported from a 
DLL). I suspect this is to make things behave more like they do with 
Shared Objects on Linux or similar.


The PE/COFF base relocation format is more compact than the ELF64 
relocation formats:
ELF64 tends to spend 24 bytes for every symbol, and 24 bytes for each 
reloc; along with an ASCII string for every symbol.

It also tends to redirect most calls and loads/stores for global 
variables through the GOT, rather than using PC-relative / RIP-relative 
addressing (or fixed displacements relative to a Global Pointer), 
causing the generated code to be larger (along with the size of the GOT).


That said, if comparing against a compiler like MSVC, the theoretical 
advantage of the PE/COFF format tends to be offset by MSVC tending to 
generate somewhat bulkier machine-code than GCC (and "/Os" can't really 
fix the issue as it doesn't really seem to work in modern versions, *2).

*2: Seemingly the main way I am aware of to get small binaries is to use 
an older version of MSVC (such as 6.0 to 9.0), as the binary-bloat 
started to get much more obvious around Visual Studio 2010, but is less 
of an issue with VS2005 or VS2008.

But, it is a tradeoff as these older versions of MSVC have some 
annoyances as well (they only really support C89, don't have any special 
handling for constant-sized "memcpy()", etc). They do also have the 
merit though that they can still compile EXE's that work on WinXP.



So, it doesn't matter as much if the metadata is smaller, when the 
".text" section is significantly larger.

More so, GCC allows "-ffunction-sections" and "-fdata-sections" and 
similar, which can save a fair chunk of space for many programs (by 
omitting any functions and variables that aren't directly reachable from 
the linked program).

Also, with GCC, "-Os" tends to work and is moderately effective (though, 
"-O3" is faster, and often not significantly larger); as well, GCC 
output tends to be faster than MSVC output (though depends a lot on the 
program).

....

But, some of this is just what I have seen.