[Issue 5484] New: GC segfaults on FreeBSD 64 / scanning issues for .data and .bss sections

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5484

           Summary: GC segfaults on FreeBSD 64 / scanning issues for .data
                    and .bss sections
           Product: D
           Version: D2
          Platform: All
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: druntime
        AssignedTo: nobody at puremagic.com
        ReportedBy: dawg at dawgfoto.de


--- Comment #0 from dawg at dawgfoto.de 2011-01-25 11:34:53 PST ---
Created an attachment (id=877)
elf64-x86-64-freebsd

IMHO FreeBSD is missing _data__start/_data__end/_bss_start__/_bss_end__
symbols.
The current strategy is to use etext and _end as scanning range.

>From compiling "void main() {}"
-m32:
nm out | grep etext -> 08055b38 A etext
nm out | grep _end  -> 0805ba04 A _end

-m64:
nm out | grep etext -> 0000000000411012 A etext
nm out | grep _end  -> 0000000000619988 A _end


This is not optimal as it spans over some read only sections but it's a minor
issue for 32.
With elf64-x86-64-freebsd there is a big non-readable area between .eh_frame
and .tdata. This leads to segfaulting when running the garbage collector.
I don't know any portable/official solution to this but observed that _progname
is always the first symbol in .data for 32/64 bit.

The boehm collector is installing a signal handler and tries to read from _end
upwards until it fails.

I've appended objdump section headers.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------