Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sat, 1 Jun 2024 11:24:20 +0100
Organization: A noiseless patient Spider
Lines: 120
Message-ID: <v3essl$2nsh7$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> <yMo6O.3723$zfC8.2197@fx35.iad>
 <v3dem9$2d2v4$1@dont-email.me> <TLu6O.6222$xPJ1.816@fx09.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 01 Jun 2024 12:24:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="91ec5d79126354b953c01cb00293891d";
	logging-data="2880039"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX190oop1j06aG5i+TkBZ5X5L"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lygjzPR2mnHV8SaHUrKCOsnKMhU=
In-Reply-To: <TLu6O.6222$xPJ1.816@fx09.iad>
Content-Language: en-GB
Bytes: 5222

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:
>>
>>      printf("%p\n", &_binary_hello_c_start);
>>      printf("%p\n", &_binary_hello_c_end);
>>      printf("%p\n", &_binary_hello_c_size);
>>
>> I get:
>>
>>      00007ff6ef252010
>>      00007ff6ef252056
>>      00007ff5af240046
>>
>> I can see that the first two can be subtracted to give the sizes of the
>> data, which is 70 or 0x46. 0x46 is the last byte of the address of
>> _size, so what's happening there? What's with the crap in bits 16-47?
>>
>> I can extract the size using:
>>
>>     printf("%d\n", (unsigned short)&_binary_hello_c_size);
>>
>> But something is not right. I've also asked what is the point of the
>> -size symbol if you can just do -end - -start, but nobody has explained.
> 
> $ 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
-------------------------------------

Maybe Windows is at fault? I'll try it under WSL:

-------------------------------------
root@DESKTOP-11:/mnt/c/c# objcopy -I binary -O elf64-x86-64 main.cpp test.o
root@DESKTOP-11:/mnt/c/c# gcc m.c test.o -o m
root@DESKTOP-11:/mnt/c/c# ./m
0x55effc9f2046
0x55effc9f6010
0x55effc9f6056
-------------------------------------

Nope, same thing. This doesn't inspire much confidence. With values 
shown, the actual size IS contained within the _size value, but only as 
the last 16 bits of the value.

gcc versions were 10.3.0 and 9.4.0 respectively; the latter is what is 
provided by Windows 11.

You also brought up the fact that the size is not known to the compiler 
anyway, which means a few things are not possible, like using the size 
in a static context.