Using gcc as a sort of scripting language.

[Paul Markfort via Gcc]

This is just a suggestion to make it easier for Linux/Unix users to use the Gnu 
compilers instead of having to use a scripting language for short little 
utilities.

I know someone has created and released a binary C interpreter for this purpose.
But why would you want to install another program, if you could essentially use 
the tools you already have.

I think gcc (and all the compilers) should support the "#!" in source files to 
make something similar easily possible.
So one could write C or C++ (or Fortran, etc) code and just run the source file 
to compile and run.

The Best way to make this possible is to set up the compiler to ignore "#!" if 
it is the first line.
Maybe a special pre-processor would work as well, but it is nice if one can 
send the unmodified source through the standard compilers (the edit and run 
process is a quick way to try out ideas before creating a full program).

This could encourage people to do this more often (increasing the utility of 
writing short compiled scripts) if one could do the below by simply starting 
the source file with:

#! /usr/bin/compile-and-run-file.sh -v


Currently, to do this (with C and C++) one needs to start their code similar to 
this (this works, I have tested it):


#if 0   /*  (first line is blank on purpose)
#   Warning, the following will usually be run by sh (not bash, nor 
csh)
#   If you make this file executable - it will be processed by the 
script below.
compile-and-run-file.sh -v "${0}" "${@}"
exit
#   End of C comment*/
#endif





I have a complete example here (including the complile-and-run-file.sh script):
http://www.paulfm.com/~paulfm/share/code/make-scratch/

Note: I am not a very good C/C++ programmer, so I don't pretend to have the 
best answer (this is just an example of one way to do this).


Thanks.


--

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/

gcc-12-20241226 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20241226 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20241226/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 421e27ecc6611fe8fbb2cdf639deac1f07b729fa

You'll find:

 gcc-12-20241226.tar.xz   Complete GCC

  SHA256=b79d4d98dcdb9e67298524cad6a221926023c69c4ffdb6930105f8e45b133a84
  SHA1=1fe97b5e997ca7d4c0f0ea69c05e3928904b6823

Diffs from 12-20241219 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

GDB debugging showing wrong code

[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?

Thanks
Trampas