Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: objcopy -I binary etc... Was: C23 thoughts and opinions
Date: Thu, 6 Jun 2024 14:56:33 +0300
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <20240606145633.000061f5@yahoo.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>
	<86bk4kp50e.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 06 Jun 2024 13:56:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e60a8e6a76916644fa1bcd4273b02481";
	logging-data="1497433"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uhdFExFKkOFq42kGD4UVDUSW58mmoSlo="
Cancel-Lock: sha1:aaJqkKoJj2iu7qjyRuo8S3OJQnY=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5666

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.