Re: C23 thoughts and opinions

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.