On 6/3/22 10:16, Janne Blomqvist via Fortran wrote:
On Fri, Jun 3, 2022 at 10:30 AM Arjen Markus via Fortran
<fortran@gcc.gnu.org> wrote:

Hi Kay,

(you forgot to reply to everybody ;))

I am using a Windows version of gfortran and strings. I use a file viewer
that comes with the Total Commander file manager. So, it may be something
specific to that version of strings.

One caveat being that Fortran strings are not NULL terminated like C
strings. So a tool that searches for C-style strings in a binary might
not find Fortran-style strings unless there happens to be a NULL after
them for some other reason. The version of strings included in GNU
binutils searches for strings terminated by any non-printable
character, so it finds Fortran style strings (and a lot of noise which
isn't strings).

Op vr 3 jun. 2022 om 09:25 schreef Kay Diederichs <
kay.diederi...@uni-konstanz.de>:
@Janne thanks for pointing out that -g does not make the code slower.
Is there an option that prevents the sourcecode to be included when -g is
used?

You might try -frecord-gcc-switches. There's also
-grecord-gcc-switches (which puts the info somewhere in the debug
data), which is enabled by -g, but without -g it seems it doesn't do
anything.


thanks for pointing at -frecord-gcc-switches . This appears to be what I was 
looking for.
Googling for frecord-gcc-switches (without the leading "-", of course) brings 
up very interesting exchanges.
For the record, when -frecord-gcc-switches  is used in compilation,
objdump -s --section=.GCC.command.line <binary>
or
readelf -p .GCC.command.line <binary>
shows the compiler options.
I have not (yet) tried to find out how -grecord-gcc-switches differs, nor if 
and why the suggestion to
"Introduce a new GCC option, --record-gcc-command-line" was rejected
( https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg00434.html ).

Thanks to all who responded!
Kay

Reply via email to