Re: Link-time resolved constant
I am a newbie, but if you want my opinion you are welcome to it. My thoughts are that for growth to happen you often need creative destruction. That is to destroy or tear down the old ways and create something better. In that respect the old way of doing things will never agree to self destruction. Therefore create a new file format for the elf and call it elf2 or any name you want, then let the results be so good that no one can ignore them. Do not ask permission from the old way as it will resist change. Fork and move forward, when done let the results and quality speak for themself. Dennis Ritchie built C not Ada++. Basically tore down the past and recreated a better future. He did it so well that no one could ignore his results. By the growth of new languages like Rust and Zig, it is appearing that C will be around forever, but needs a replacement. If elf format needs a replacement as well, then so be it. Just do not expect rapid adoption until there is monetary value in doing so. For example, even with Zig and Rust, C will be around for decades to come in the embedded world because the old programmers know C. As such the old elf files and old ways of doing things will be around for a long time. The change from the old ways will happen only when the new ways are more profitable and/or easier for the guy doing the work. On Tue, Jan 7, 2025 at 11:36 AM The Cuthour via Gcc wrote: > Previous thread on binutils > https://sourceware.org/pipermail/binutils/2025-January/138334.html > > I'd like to hear your opinion. > Can we once again promise that only modified files need to be recompiled? >
Re: GDB debugging showing wrong code
Thanks Richard!
I have requested an account with the gcc bugzilla system.
Trampas
On Fri, Dec 27, 2024 at 5:05 AM Richard Biener
wrote:
>
>
> > Am 27.12.2024 um 02:50 schrieb Trampas Stern via Gcc :
> >
> > I am doing embedded development on an arm cortex-m processor using
> > arm-none-eabi-gcc. I have run into a bug where GDB is showing that the
> > code executing is code from a function that is not used. The code is
> > removed as it is not called, and hence -ffunction-sections
> -fdata-sections
> > -Wl,--gc-sections has removed it.
> > The issue appears that sometime around January 2022 with introduction of
> > GCC 11 the elf file output changed to including these function symbols
> and
> > then mapping them to address zero.
> >
> > The result is that there are several function symbols mapped to address 0
> > and then gdb seems to randomly pick which code it thinks is running. For
> > example when running a loop like:
> > int i=100;
> > while (i>0) {
> > i--;
> > }
> > GDB might decide the i--; is some other random line in a seemingly random
> > file/function that is not in the binary image. As such stepping through
> > code it will jump between random locations.
> >
> > I have found that the 10.3.1 toolchain does not have this issue, but
> every
> > one I have tried after and including 11.2.1 has this issue. I seem to
> > recall around GCC 11 there was a change for -flto and was wondering if
> this
> > created this issue?
> >
> > I have noticed that when I build elf files with both versions of code the
> > failing version will have errors in the objdump -dlr output. For
> example:
> >
> > Disassembly of section .text:
> >
> > :
> > getStackSize():
> >
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:244
> > 0: ff 7f 00 20 95 04 00 00 5d 05 00 00 9d 05 00 00 ... ]...
> > ...
> > getStackUsed():
> >
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:254
> > 2c: 5d 05 00 00 00 00 00 00 00 00 00 00 5d 05 00 00 ]...]...
> >
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:257
> > 3c: c5 08 00 00 5d 05 00 00 f9 0b 00 00 65 06 00 00 ]...e...
> >
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:250
> > 4c: 5d 05 00 00 5d 05 00 00 5d 05 00 00 5d 05 00 00 ]...]...]...]...
> >
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:267
> > 5c: 5d 05 00 00 99 07 00 00 bd 07 00 00 e1 07 00 00 ]...
> > 6c: 05 08 00 00 29 08 00 00 4d 08 00 00 5d 05 00 00 )...M...]...
> > _ZN10I2C_MASTER4syncEv():
> > D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:90
> > 7c: 5d 05 00 00 5d 05 00 00 e9 09 00 00 29 0a 00 00 ]...]...)...
> > _ZN10I2C_MASTER18setCommandBitsWireEh():
> > D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:90
> >
> > In the above the objdump is confused and mixing the getStackSize()
> function
> > (is not in binary) with the exception vector table. As you can see in
> the
> > listing above the objdump seems to change which function it is guessing
> > should be used changing to _ZN10I2C_MASTER4syncEv(): and then
> > _ZN10I2C_MASTER18setCommandBitsWireEh():
> >
> > I found this continues into real function and yields weird results when
> > stepping through code in a debugger (gdb).
> >
> > I have tried -flto and everything else to remove these unused symbols
> from
> > the elf file and nothing seems to work.
> >
> > Is this a bug in the toolchain? Is there a possible work around?
>
> I suggest you file a bugzilla Report with a reproducer.
>
> Richard
>
> > Thanks
> > Trampas
>
Re: Using gcc as a sort of scripting language.
I had about the same thought 20 some years ago. I also wanted a more advanced preprocessor which had more scripting capabilities, with knowledge of the C lexical output. For example write a preprocessor script that would call a macro every time a function call was entered. I also always wondered why there was not a python C interpreter. That is, I thought about writing a C function and having a python script which tested the C code, where C code was run through an interpreter in python. There was no reason to compile the C code if python could just interpret the C code for testing. I really liked this idea as it would mean you could use C as scripting language as you suggested. It would have to have some json configuration to provide information on the endian, size of integer, and basically all the machine specific information you need for C. Which is where the problem comes in. This machine specific details is the hard part. For example is an integer 16bit, 32bit or 64bit. If it is machine specific then your script is not portable. If you have a machine configuration, then that needs to be included with script, which is a pain. At the end of the day it ends up that python is close enough to C that it is easier to use python for scripting. However I still want the C/C++ interpreter in python for testing C/C++ code. Having done opensource projects before I learned that the idea creates no value, it is the guy who implements it that creates value. Also I learned that most people use open source, but a very very small percentage actually contribute to it. So basically if it is a great idea, go make it happen! Note I have not done the python interpreter for C/C++ On Sat, Dec 28, 2024 at 10:01 AM Paul Markfort via Gcc wrote: > To be clear. > > I am not suggesting that Compilers like GCC be modified to act on the > "#!", or even fully support it. > Just that they be simply modified to ignore "#!" - on the first line > (which should terminate with either a "/r" or "/n"). > This allows the easy creation of scripts to handle an executable Source > file. > Maybe ignore all lines beginning with "#!" - as this would make it easy to > add a line with extra arguments for a script or program that runs the > source file. The compiler itself doesn't need to have any special features > to do that. > I realize that C is not a line oriented language and usually completely > ignores line termination characters (so yes this is probably not a simple > thing to do). > > The point is to make it easier to use C and C++ (and Fortran, etc) to > write small little utility programs. > This will also make it much easier to teach these languages - and for > students (or anyone) to practice ideas. > > Compilation of small source files is so fast these days, that an > interpreter probably is a sub-optimal solution. > Compile, then run helps find errors before the program does anything (One > example of this is perl - which compiles the perl code, then runs it). We > don't need to get into the details of how this would be used - or what the > program that gets started by running the source needs to be able to do. > > > > On 2024-12-28 5:48 AM, Basile Starynkevitch wrote: > > Hello all, > > > > Paul Markfort suggested > >> .. > -- > > The views and opinions expressed above are strictly > those of the author(s). The content of this message has > not been reviewed nor approved by any entity whatsoever. > > Paul FM Info: http://paulfm.com/~paulfm/ > >
GDB debugging showing wrong code
I am doing embedded development on an arm cortex-m processor using
arm-none-eabi-gcc. I have run into a bug where GDB is showing that the
code executing is code from a function that is not used. The code is
removed as it is not called, and hence -ffunction-sections -fdata-sections
-Wl,--gc-sections has removed it.
The issue appears that sometime around January 2022 with introduction of
GCC 11 the elf file output changed to including these function symbols and
then mapping them to address zero.
The result is that there are several function symbols mapped to address 0
and then gdb seems to randomly pick which code it thinks is running. For
example when running a loop like:
int i=100;
while (i>0) {
i--;
}
GDB might decide the i--; is some other random line in a seemingly random
file/function that is not in the binary image. As such stepping through
code it will jump between random locations.
I have found that the 10.3.1 toolchain does not have this issue, but every
one I have tried after and including 11.2.1 has this issue. I seem to
recall around GCC 11 there was a change for -flto and was wondering if this
created this issue?
I have noticed that when I build elf files with both versions of code the
failing version will have errors in the objdump -dlr output. For example:
Disassembly of section .text:
:
getStackSize():
D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:244
0: ff 7f 00 20 95 04 00 00 5d 05 00 00 9d 05 00 00 ... ]...
...
getStackUsed():
D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:254
2c: 5d 05 00 00 00 00 00 00 00 00 00 00 5d 05 00 00 ]...]...
D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:257
3c: c5 08 00 00 5d 05 00 00 f9 0b 00 00 65 06 00 00 ]...e...
D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:250
4c: 5d 05 00 00 5d 05 00 00 5d 05 00 00 5d 05 00 00 ]...]...]...]...
D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:267
5c: 5d 05 00 00 99 07 00 00 bd 07 00 00 e1 07 00 00 ]...
6c: 05 08 00 00 29 08 00 00 4d 08 00 00 5d 05 00 00 )...M...]...
_ZN10I2C_MASTER4syncEv():
D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:90
7c: 5d 05 00 00 5d 05 00 00 e9 09 00 00 29 0a 00 00 ]...]...)...
_ZN10I2C_MASTER18setCommandBitsWireEh():
D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:90
In the above the objdump is confused and mixing the getStackSize() function
(is not in binary) with the exception vector table. As you can see in the
listing above the objdump seems to change which function it is guessing
should be used changing to _ZN10I2C_MASTER4syncEv(): and then
_ZN10I2C_MASTER18setCommandBitsWireEh():
I found this continues into real function and yields weird results when
stepping through code in a debugger (gdb).
I have tried -flto and everything else to remove these unused symbols from
the elf file and nothing seems to work.
Is this a bug in the toolchain? Is there a possible work around?
Thanks
Trampas
Re: Link-time resolved constant
Go do it! Do it so well and with such high quality that no one can ignore the results! On Tue, Jan 7, 2025 at 1:26 PM The Cuthour wrote: > Thank you. > > My plan is to make a higher compatibility version of ELF. > You may be able to call it ELF2.0 >
