[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) -
From: |
Mike Thomas |
Subject: |
RE: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS |
Date: |
Fri, 9 Jul 2004 14:07:55 +1000 |
Hi Camm.
| Greetings!
|
| OK, we have another relocation error, it appears.
Thanks very much for that.
| The issue appears to be that the code in sfasl.c does not handle the
| .rodata section in which recent gcc is apparently placing the jump
| table addresses used by the switch statement. We need the analogous
| RODATA_NSCN in ext_sym.h, plus logic to setup a s_start_rodata in
| struct sfasl_info in sfasl.c. Check out objdump -r and objdump -d on
| clmacs.o.
On Windows these sections are called ".rdata".
| I wonder how many other sections there are like this.
It turns out there are quite a few. The official Microsoft PE-COFF docs are
in PDF but I found a text version here for you:
http://www.lisoleg.net/lisoleg/elfandlib/Microsoft%20Portable%20Executable%2
0COFF%20Format%20Specification.txt
Herein:
"Typical COFF sections contain code or data that linkers and Win32 loaders
process without special knowledge of the sections!? contents. The contents
are relevant only to the application being linked or executed.
However, some COFF sections have special meanings when found in object files
and/or image files. Tools and loaders recognize these sections because they
have special flags set in the section header, or because they are pointed to
from special locations in the image optional header, or because the section
name is !?magic!?: that is, the name indicates a special function of the
section. (Even where the section name is not magic, the name is dictated by
convention, so we will refer to a name.)
The reserved sections and their attributes are described in the table below,
followed by detailed descriptions for a subset of them.
Section Name Content Characteristics
.arch Alpha architecture information IMAGE_SCN_MEM_READ |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_8BYTES |
IMAGE_SCN_MEM_DISCARDABLE
.bss Uninitialized data IMAGE_SCN_CNT_UNINITIALIZED_DATA |
IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.data Initialized data IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ |
IMAGE_SCN_MEM_WRITE
.edata Export tables IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
.idata Import tables IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ |
IMAGE_SCN_MEM_WRITE
.pdata Exception information IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ
.rdata Read-only initialized data IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ
.reloc Image relocations IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ
| IMAGE_SCN_MEM_DISCARDABLE
.rsrc Resource directory IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ
| IMAGE_SCN_MEM_WRITE
.text Executable code IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE |
IIMAGE_SCN_MEM_READ
.tls Thread-local storage IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.xdata Exception information IMAGE_SCN_CNT_INITIALIZED_DATA |
IMAGE_SCN_MEM_READ
Some of the sections listed here are marked !?(object only)!? or !?(image
only)!? to indicate that their special semantics are relevant only for
object files or image files, respectively. A section that says !?(image
only)!? may still appear in an object file as a way of getting into the
image file, but the section has no special meaning to the linker, only to
the image file loader."
Add to these at least GCC's ".stab" and ".stabstr" and your ".rodata".
| Just one more
| piece of incentive to try to centralize around bfd on mingw at some
| point.
Yes, except for the GPL rather than LGPL licencing which I'm still trying to
minimise and the apparent? divergence of our BFD usage from the modern
recommended method, which leaves Windows GCL in an unsupported part of the
BFD library.
| sfasl.c needs serious cleaning at the very least I think.
Agreed. I've already added much of what is needed to at least get ".rdata"
support up for the time being but although GCL self-builds I still haven't
got Maxima past the original specfn hurdle yet. At least this time around I
have a better understanding of the system than last time.
Cheers
Mike Thomas.
- RE: [Gcl-devel] memory damaged at (system:STRING-MATCH :anykey :verbose), Mike Thomas, 2004/07/05
- Re: [Gcl-devel] memory damaged in Maxima, Michael Koehne, 2004/07/05
- Re: [Gcl-devel] memory damaged at (system:STRING-MATCH :anykey :verbose), Camm Maguire, 2004/07/06
- RE: [Gcl-devel] memory damaged at (system:STRING-MATCH :anykey:verbose), Mike Thomas, 2004/07/07
- Re: [Gcl-devel] memory damaged at (system:STRING-MATCH :anykey:verbose), Camm Maguire, 2004/07/07
- RE: [Gcl-devel] memory damaged at (system:STRING-MATCH:anykey:verbose), Mike Thomas, 2004/07/07
- Re: [Gcl-devel] memory damaged at (system:STRING-MATCH:anykey:verbose), Camm Maguire, 2004/07/07
- RE: [Gcl-devel] memory damaged at (system:STRING-MATCH:anykey:verbose), Mike Thomas, 2004/07/07
- RE: [Gcl-devel] memory damaged at (system:STRING-MATCH:anykey:verbose) - PS, Mike Thomas, 2004/07/08
- Re: [Gcl-devel] memory damaged at (system:STRING-MATCH:anykey:verbose) - PS, Camm Maguire, 2004/07/08
- RE: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS,
Mike Thomas <=
- Re: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS, Camm Maguire, 2004/07/12
- RE: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS, Mike Thomas, 2004/07/12