On 18/01/2018 17:38, Jaroslav Skarvada wrote:
----- Original Message -----
Out of curiosity I ran rpmlint on wsjtx and most of the output was pretty
much what I expected but one line in particular caught my eye.
wsjtx.x86_64: W: executable-stack /usr/bin/jt9
$ rpmlint -I executable-stack
executable-stack:
The binary declares the stack as executable. Executable stack is usually an
error as it is only needed if the code contains GCC trampolines or similar
constructs which uses code on the stack. One common source for needlessly
executable stack cases are object files built from assembler files which
don't
define a proper .note.GNU-stack section.
Is this due to fortran?
Thanks,
Richard
I debugged it down to the lib/decoder.f90.o.
With GCC/gfortran there is a workaround to compile it with:
$ gfortran -Wa,--noexecstack ...
But it is not portable and doesn't resolve the source of the problem.
It's better to fix it in the code. It seems there are no assembler
sources and I verified that the GNU_STACK is present. With C I know
compiler can create exec stacks if you use trampolines in the code.
But my Fortran skills are really lame. Could anybody help to locate
the source of the problem in Fortran sources?
thanks & regards
Jaroslav
Hi Jaroslav and Richard,
that issue that Mike posted suddenly makes things clear to me. It would
appear that Fedora is somehow enforcing that stack should not be
executable. This is not compatible with WSJT-X's use of Fortran function
pointers which are implemented in GNU Fortran as trampolines on the
stack if global variables are used, which they are.
Michael, KJ6VCP's, crash dump shows that the crash is happening when jt9
attempts to call the function pointer in question. This is consistent
with the NX bit (or software equivalent) being set for the stack area of
memory.
Setting the assembler option --noexecstack will not help as it is only a
hint to set any unmarked stack section to not be executable. The linker
option "-z noexecstack" is similar. If you examine the decode.f90 object
file:
readelf -SW
~/wsjtx-prefix/dev/build/Debug/CMakeFiles/wsjt_fort.dir/lib/decoder.f90.o
you will see it's stack section is marked as executable (X) which is
correct. That will force the whole executable to have an executable
stack, which is also correct. Any action to make the stack
non-executable will cause the program to crash on decode.
If Fedora is forcing all processes to have non-executable stacks then we
have a serious issue.
If someone having issues with crashes on decode on Fedora can check if
the executable stack flag has been removed from the jt9 executable, that
would help with analysis. Use the following command:
readelf -lW `which jt9` | grep GNU_STACK
which should produce a line something like:
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10
where the 'E' in the 'RWE' part shows that the stack will be correctly
marked as executable. If that is missing then the application is not valid.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
