objcopy -I binary etc... Was: C23 thoughts and opinions

On Sat, 01 Jun 2024 17:22:57 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

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)). 

 

Except that typically on Linux gcc and clang use the same linker.

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.

I reproduced your findings. The difference between gcc and clang is not
in ld, but in ld invocation options.
Specifically, gcc calls ld with -pie, clang calls ld without it.
gcc default behaviour can be overwritten with -no-pie switch.
I suppose that gcc4 has the same default as clang.