[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: Camm Maguire
Subject: Re: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS
Date: 12 Jul 2004 14:28:57 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


"Mike Thomas" <address@hidden> writes:

> 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:

OK, from the list below, I still think we might only need rdata.  I
think the other 'data' sections refer to c++.  We need only worry
about sections with relocatable objects therein, so .stabs et. al. are
not a problem.

> 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 |
> .bss  Uninitialized data      IMAGE_SCN_CNT_UNINITIALIZED_DATA |
> .data Initialized data        IMAGE_SCN_CNT_INITIALIZED_DATA | 
> .edata        Export tables   IMAGE_SCN_CNT_INITIALIZED_DATA | 
> .idata        Import tables   IMAGE_SCN_CNT_INITIALIZED_DATA | 
> .pdata        Exception information   IMAGE_SCN_CNT_INITIALIZED_DATA |
> .rdata        Read-only initialized data      IMAGE_SCN_CNT_INITIALIZED_DATA |
> .reloc        Image relocations       IMAGE_SCN_CNT_INITIALIZED_DATA | 
> |                IMAGE_SCN_MEM_DISCARDABLE
> .rsrc Resource directory      IMAGE_SCN_CNT_INITIALIZED_DATA | 
> |                 IMAGE_SCN_MEM_WRITE
> .text Executable code IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE |
> .tls  Thread-local storage    IMAGE_SCN_CNT_INITIALIZED_DATA |
> .xdata        Exception information   IMAGE_SCN_CNT_INITIALIZED_DATA |
> 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.

Interesting.  And to me the biggest difficulty was the 1.5Meg extra
memory consumption!  The license issue always seemed insignificant to
me given our current and likely future user base.  And I'm not sure
how unsupported the code we use is, though it is definitely different
from that used by ld.  They've recently added functions on 'our side',
like bfd_get_simple_relocated_section_contents, or some such.

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

Great!  Please let me know if you get stuck or need another pair of
eyes.  Just figuring out the proper value of the relocation in this
example, and stepping through in gdb to make sure that is handled
correctly, will likely solve the whole thing.

Take care,

> Cheers
> Mike Thomas.

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]