Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sat, 01 Jun 2024 05:17:12 -0700
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <86frtwq2lz.fsf@linuxsc.com>
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> <yMo6O.3723$zfC8.2197@fx35.iad> <v3dem9$2d2v4$1@dont-email.me> <TLu6O.6222$xPJ1.816@fx09.iad> <v3essl$2nsh7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 01 Jun 2024 14:17:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="82e6856672d268f6992b64e1b7017ac6";
	logging-data="2918189"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Wzi1zxlKeKYiM2JKVqQJ2GfN7s6IvXi0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:UdO3eI0lzolXD8QT3EYJevXoy6E=
	sha1:9cqjUGdjPFj752OoyA2qoaldk2o=
Bytes: 4745

bart <bc@freeuk.com> writes:

> On 01/06/2024 02:25, Scott Lurndal wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> Little of this seems to work, sorry.  You guys keep saying, do this, do
>>> that, no do it that way, go RTFM, but nobody has shown a complete
>>> program that correctly shows the -size symbol to be giving anything
>>> meaningful.
>>>
>>> If I run this:  [attempt to reproduce example]
>>
>> $ cat /tmp/m.c
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> extern uint64_t _binary_main_cpp_size;
>> extern uint8_t *_binary_main_cpp_start;
>> extern uint8_t *_binary_main_cpp_end;
>>
>> int main()
>> {
>>      printf("%p\n", &_binary_main_cpp_size);
>>      printf("%p\n", &_binary_main_cpp_start);
>>      printf("%p\n", &_binary_main_cpp_end);
>>      return 0;
>> }
>> $ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
>> $ cc -o /tmp/m /tmp/m.c /tmp/test.o
>> $ /tmp/m
>> 0x30e2
>> 0x601034
>> 0x604116
>> $ nm /tmp/m | grep _binary_main
>> 0000000000604116 D _binary_main_cpp_end
>> 00000000000030e2 A _binary_main_cpp_size
>> 0000000000601034 D _binary_main_cpp_start
>> $ wc -c main.cpp
>> 12514 main.cpp
>> $ printf 0x%x\\n 12514
>> 0x30e2
>>
>> The size symbol requires no space in the resulting
>> executable memory image, and it's more convenient than
>> having to do the math (at run time, since the compiler
>> can't know the actual values).
>
> Here's my transcript:
>
> -------------------------------------
> C:\c>copy hello.c main.cpp         # create main.cpp, here it's 70 bytes
>         1 file(s) copied.
>
> C:\c>type m.c                      # exact same code as yours
> #include <stdio.h>
> #include <stdint.h>
>
> extern uint64_t _binary_main_cpp_size;
> extern uint8_t *_binary_main_cpp_start;
> extern uint8_t *_binary_main_cpp_end;
>
> int main()
> {
>     printf("%p\n", &_binary_main_cpp_size);
>     printf("%p\n", &_binary_main_cpp_start);
>     printf("%p\n", &_binary_main_cpp_end);
>     return 0;
> }
>
> C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o  # make test.o
>
> C:\c>gcc m.c test.o -o m.exe       # build m executable
>
> C:\c>m                             # run m.exe
> 00007ff5d5480046                   # and the size is ...
> 00007ff715492010
> 00007ff715492056
> 
> [similar results under WSL]

For what it's worth I see the same behavior running on linux.
It looks like the culprit is gcc, which apparently relocates
the symbol even though it is marked with an A type.  After
running around in circles for a goodly amount of time, it
occurred to me to try compiling using clang, and that worked.

I suppose it's good to know about the &_binary_main_cpp_size
trick, but it's kind of the worst of both worlds:  the size
is baked into the executable (or half-baked I might say), but
the value can't be used at compile time.  Bleah.  If I wanted
to use the objcopy method of inserting raw text into a C
program, I would either do a run-time subtraction to find out
what the size is, or simply add an extra step to the makefile
to extract the size out of the 'nm' output and produce a .h
file with a (named) value that could be used at compile time.
And both of these methods work under gcc as well as clang.