#include <execinfo.h> int main() { void *data[100]; backtrace(data, 100); return 0; } ----- libgcc_s.so.1: file format elf64-alpha Program Header: LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**16 filesz 0x000000000000a1fc memsz 0x000000000000a1fc flags r-x LOAD off 0x000000000000a200 vaddr 0x000000000001a200 paddr 0x000000000001a200 align 2**16 filesz 0x0000000000000f40 memsz 0x0000000000000fd0 flags rwx DYNAMIC off 0x000000000000ac08 vaddr 0x000000000001ac08 paddr 0x000000000001ac08 align 2**3 filesz 0x00000000000001b0 memsz 0x00000000000001b0 flags rw- EH_FRAME off 0x0000000000009fd0 vaddr 0x0000000000009fd0 paddr 0x0000000000009fd0 align 2**2 filesz 0x000000000000022c memsz 0x000000000000022c flags r-- STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3 filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx ---- Program received signal SIGSEGV, Segmentation fault. 0x0000020000006770 in _dl_map_object_from_fd ( name=0x20000159730 "libgcc_s.so.1", fd=0, fbp=0x200001af1d0, realname=0x120012010 "./libgcc_s.so.1", loader=0x200001af140, l_type=536865984, mode=0, stack_endp=0x11ffff1d8) at dl-load.c:1307 1307 __stack_prot |= PROT_EXEC; (gdb) where #0 0x0000020000006770 in _dl_map_object_from_fd ( name=0x20000159730 "libgcc_s.so.1", fd=0, fbp=0x200001af1d0, realname=0x120012010 "./libgcc_s.so.1", loader=0x200001af140, l_type=536865984, mode=0, stack_endp=0x11ffff1d8) at dl-load.c:1307 #1 0x00000200000076c4 in _dl_map_object (loader=0x0, name=0x20000159730 "libgcc_s.so.1", preloaded=0, type=0, trace_mode=0, mode=268435457) at dl-load.c:1989 #2 0x000002000013be58 in dl_open_worker (a=0x20000015231) at dl-open.c:240 #3 0x000002000000c534 in _dl_catch_error (objname=0x11ffff460, errstring=0x11ffff468, operate=0x2000013bd40 <dl_open_worker>, args=0x11ffff430) at dl-error.c:161 #4 0x000002000013c7f4 in *__GI__dl_open (file=0x20000159730 "libgcc_s.so.1", mode=1, caller_dlopen=0x0) at dl-open.c:533 #5 0x000002000013df68 in do_dlopen (ptr=0x11ffff620) at dl-libc.c:80 #6 0x000002000000c534 in _dl_catch_error (objname=0x11ffff600, errstring=0x11ffff608, operate=0x2000013df40 <do_dlopen>, args=0x11ffff620) at dl-error.c:161 #7 0x000002000013dee4 in dlerror_run (operate=0x97, args=0x0) at dl-libc.c:42 #8 0x000002000013e030 in *__GI___libc_dlopen_mode ( name=0x20000015231 "info[20]->d_un.d_val == 7", mode=0) at dl-libc.c:154 #9 0x0000020000112b5c in init () at backtrace.c:40 #10 0x0000020000112d14 in __backtrace (array=0x20000015231, size=100) at backtrace.c:78 ---- I tried to reproduce this with an arbitrary library opened with dlopen, but I couldn't. But I've seen this with libgcc_s.so.1 and libnss_db.so.2, so perhaps there's something special about the path used internally by libc. I guess this is a mixed blessing because libgcc_s.so.1 isn't *supposed* to be marked with executable stack, but it appears that the bits that intend to turn it off have never worked.
Well, the bits work on most arches: readelf -Wa /lib/libgcc_s.so.1 /lib64/libgcc_s.so.1 | grep GNU_STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8 on x86-64 e.g. I guess Alpha links some .asm/.s/.S files into libgcc_s.so.1 and those don't have the magic #ifdef __linux__ .section .note.GNU-stack,""; .previous #endif in them (e.g. ppc32 has this).
Subject: Re: ld.so crashes if libgcc_s.so.1 has an executable stack On Thu, Sep 30, 2004 at 07:16:53PM -0000, jakub at redhat dot com wrote: > I guess Alpha links some .asm/.s/.S files into libgcc_s.so.1 and those don't > have the magic > #ifdef __linux__ > .section .note.GNU-stack,""; .previous > #endif > in them (e.g. ppc32 has this). Yes, I suppose so, but I havn't found it yet. It's sort of annoying that ld doesn't put this information into the -Map file... r~
I'll close this report. I cannot see how libgcc is special and I couldn't reproduce it. Reopen if it still happens.