Path: csiph.com!news.swapon.de!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 17:22:57 -0700
Organization: A noiseless patient Spider
Lines: 105
Message-ID: <86bk4kp50e.fsf@linuxsc.com>
References: <v2l828$18v7f$1@dont-email.me> <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> <86frtwq2lz.fsf@linuxsc.com> <2QG6O.11963$qQk3.6582@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 02 Jun 2024 02:22:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="487e0958afb8d1cfa0659a77e612b1fd"; logging-data="3188784"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1832lBnjKsWUpICEgcWKPD1TPQ4dqmJ6V8="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:B4uQY0xB8lXySInscOW6PeHDX9A= sha1:zl7AfP8waq0mhY7cGJmOAy6Vfmk=
Xref: csiph.com comp.lang.c:385398

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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.
>
> Which versions?   It works fine on my linux system (FC20, GCC 4.8.3)

gcc --version gives 'gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0'

>> It looks like the culprit is gcc, which apparently relocates
>> the symbol even though it is marked with an A type.
>
> gcc doesn't do 'relocations'.   If you have a problem, it's
> likely with binutils (i.e. ld(1)).

I expect you are right.  I run ld directly only rarely, and
certainly am no expert.  In my tests I was simply blindly
following the example shown in your posting (with some variations
after my attempts gave the wrong answer, trying to get it to
work).  It didn't occur to me to consider ld.

Using clang for the final link step always gave the right answer,
if I remember correctly.