#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.

------- Additional Comment #1 From Jakub Jelinek 2004-09-30 19:16 -------

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).

------- Additional Comment #2 From rth@redhat.com 2004-09-30 19:26 -------

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~

------- Additional Comment #3 From Ulrich Drepper 2005-09-23 00:57 -------

I'll close this report.  I cannot see how libgcc is special and I couldn't
reproduce it.  Reopen if it still happens.