[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 |
Greetings!
"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 |
> 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.
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
- Re: [Gcl-devel] memory damaged in Maxima, (continued)
- 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, 2004/07/09
- Re: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS,
Camm Maguire <=
- RE: [Gcl-devel] memory damaged at(system:STRING-MATCH:anykey:verbose) - PS, Mike Thomas, 2004/07/12