Message-Id: <199808122358.AAA29743@sable.ox.ac.uk>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: "George Foot" <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Thu, 13 Aug 1998 00:56:46 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [grbhat AT unigoa DOT ernet DOT in: Problem with process_coff()]
Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk
CC: djgpp-workers AT delorie DOT com, "Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>
Precedence: bulk

On 12 Aug 98 at 11:50, Eli Zaretskii wrote:

> This leads me to another aspect of the code that I find unsafe.  Look
> how lbase is computed:
> 
> >           int lbase = f_aux[i+1].x_sym.x_misc.x_lnsz.x_lnno - 1;
> 
> I'm worried about the f_aux[i+1] thing.  Here's how f_aux is defined:
> 
>   f_symtab = (SYMENT *)malloc(f_fh.f_nsyms * SYMESZ);
>   fread(f_symtab, SYMESZ, f_fh.f_nsyms, fd);
>   f_aux = (AUXENT *)f_symtab;
> 
> In other words, f_aux is an array of f_fh.f_nsyms elements, exactly
> like f_symtab is.  So f_aux[i+1] looks beyond the end of f_symtab[]
> array on the last pass through the loop, since then the index i has
> the value f_fh.f_nsyms.

I'm afraid I don't have time to look closely at this, but I thought
I'd point out that from my limited understanding of the COFF format
the above code seems perfectly valid.  IIRC, some symbol entries
require auxiliary information, and so they store a positive number in
one of their fields, to indicate the number of auxiliary entries they
require.  These auxiliary entries are stored immediately after the
symbol's main entry, and the next symbol is stored after the
auxiliary entries.

The `i+1' above is fine because (I hope) it only gets executed if
the number of auxiliary entries for symbol `i' is nonzero.  So, if
the line above is executed with "i == f_fh.f_nsyms", i.e. if the last
symbol in the table claims to have auxiliary entries, then the COFF
file is simply broken.

If you'd find it useful to browse the COFF information fairly raw, I 
wrote a COFF dumper a while ago, which writes out the debugging 
information, partially translated into English.  In any case it might 
serve as a base to write something you'd find more useful.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk