RE: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS

[Mike Thomas]

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.