#3889: configure script is generating the incorrect value for
HAVE_GNU_NONEXEC_STACK
-------------------------------+--------------------------------------------
Reporter: dmp | Owner:
Type: bug | Status: new
Priority: normal | Component: Build System
Version: 6.13 | Keywords:
Os: Linux | Testcase:
Architecture: x86_64 (amd64) | Failure: Other
-------------------------------+--------------------------------------------
My system (Fedora 12 x86_64) supports the GNU non-executable stack note,
but the configure script is not detecting it correctly. The test program
used to check for this note causes a compiler error which causes configure
to incorrectly determine the system does not support this feature. A
better test program is needed to determine if the non-executable stack is
actually supported.
This problem turns out to be the root cause of some strange behavior I
encountered, which I repeat here in case others have a similar problem. I
was attempting to verify that my programs were being dynamically linked
using {{{ldd}}}, but {{{ldd}}} was reporting that the binary was not a
dynamically linked executable. ldd was having a problem due to SELinux
which was not happy with the executable stack on the programs generated by
ghc. Looking through past tickets I found #703 which says that ghc does
generate code using the non-executable stack note. Thus I found that the
build system was not correctly setting the value.
Now to the details of the problem. The configure.ac contains the following
check to see if the system supports the non-executable stack note.
{{{
827 dnl *** check for GNU non-executable stack note support (ELF only)
828 dnl (.section .note.GNU-stack,"",@progbits)
829
830 AC_MSG_CHECKING(for GNU non-executable stack support)
831 AC_COMPILE_IFELSE(
832 [AC_LANG_PROGRAM([__asm__ (".section .note.GNU-
stack,\"\",@progbits");], [0])],
833 [AC_MSG_RESULT(yes)
834 AC_DEFINE([HAVE_GNU_NONEXEC_STACK],[1],
835 [Define to 1 if GNU non-executable stack notes are
supported.])
836 ],
837 [AC_MSG_RESULT(no)])
}}}
On my system (Fedora 12) this test generates the assembler error shown
which causes configure to incorrectly say that the compiler does not
support the non-executable stack note.
{{{
$ /usr/lib64/ccache/gcc -c -g -O2 conftest.c
/tmp/ccohqUvf.s: Assembler messages:
/tmp/ccohqUvf.s:126: Error: can't resolve `.note.GNU-stack' {.note.GNU-
stack section} - `.Ltext0' {.text section}
}}}
I believe the assembler error is related to the debug info that is
generating references to the label containing the .section .note.GNU-
stack. I've included the the generated assembly below for reference. If
the -g flag is removed the assembler error goes away.
Not being an autoconf expert I can think of two options for a better
autoconf test.
1. Don't use -g when compiling the current test program.
1. Use a variation of $ gcc -Wa,-al,--noexecstack t.c | grep '.note
.GNU-stack'
{{{
$ /usr/lib64/ccache/gcc -c -g -O2 -S conftest.c
$ cat conftest.s
.file "t.c"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
#APP
.section .note.GNU-stack,"",@progbits
#NO_APP
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB0:
.file 1 "t.c"
.loc 1 106 0
.cfi_startproc
.loc 1 110 0
xorl %eax, %eax
ret
.cfi_endproc
.LFE0:
.size main, .-main
.Letext0:
.section .debug_info
.long 0x4f
.value 0x3
.long .Ldebug_abbrev0
.byte 0x8
.uleb128 0x1
.long .LASF0
.byte 0x1
.string "t.c"
.long .LASF1
.quad .Ltext0
.quad .Letext0
.long .Ldebug_line0
.uleb128 0x2
.byte 0x1
.long .LASF2
.byte 0x1
.byte 0x69
.long 0x4b
.quad .LFB0
.quad .LFE0
.byte 0x1
.byte 0x9c
.uleb128 0x3
.byte 0x4
.byte 0x5
.string "int"
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x10
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x2e
.byte 0x0
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x17
.value 0x2
.long .Ldebug_info0
.long 0x53
.long 0x2d
.string "main"
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x2c
.value 0x2
.long .Ldebug_info0
.byte 0x8
.byte 0x0
.value 0x0
.value 0x0
.quad .Ltext0
.quad .Letext0-.Ltext0
.quad 0x0
.quad 0x0
.section .debug_str,"MS",@progbits,1
.LASF1:
.string "/home/dave/tmp"
.LASF0:
.string "GNU C 4.4.2 20091027 (Red Hat 4.4.2-7)"
.LASF2:
.string "main"
.ident "GCC: (GNU) 4.4.2 20091027 (Red Hat 4.4.2-7)"
.section .note.GNU-stack,"",@progbits
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3889>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
