Mail Archives: djgpp-workers/1998/08/12/20:00:11
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
- Raw text -