This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH-bfd] i386-mingw32-ld crash on x86_64 linux
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Peter O'Gorman <binutils at mlists dot thewrittenword dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 14 Apr 2009 15:38:40 +0100
- Subject: Re: [PATCH-bfd] i386-mingw32-ld crash on x86_64 linux
- References: <20090414140549.GH25181@tw.il.thewrittenword.com>
Peter O'Gorman wrote:
> This patch fixes the crash, though we are still unsure why it crashes
> with an x86_64 linux build and works with an i386 linux build.
Different 32-vs-64 type sizes or memory map layouts, who knows.
> 2009-04-14 Peter O'Gorman <pogma@thewrittenword.com>
>
> * peXXigen.c: Ensure in->_n._n_name is NULL terminated.
This looks wrong, for two reasons:
1. Buffer overflow: this writes one byte past the end of the _n_name array,
potentially corrupting the n_value field.
+ in->_n._n_name[SYMNMLEN] = 0;
2. Disregards the PE specification: from chapter 4 (Section table):
Offset Size Field Description
0 8 Name An 8-byte, null-padded UTF-8 encoded string. If the string is
exactly 8 characters long, there is no terminating null. For longer names,
this field contains a slash (/) that is followed by an ASCII representation of
a decimal number that is an offset into the string table. Executable images do
not use a string table and do not support section names longer than 8
characters. Long names in object files are truncated if they are emitted to an
executable file.
I think you probably need to reanalyze what's going on here. The names
aren't supposed to be nul-terminated, but we don't know for sure if gdb is
displaying them correctly; those ones with the trailing \004 are too long to
fit in the _n_name field, so ought to be stored as long section names in the
COFF string table. The other possibility is that GDB has displayed a byte too
many because it has a bug and expects nul-terminated strings, the \004 being
the low byte of n_value. If that turns out to be the case, then the
.idata$4/.idata$5 section names are actually duplicated, which could possibly
explain the problem.
Got a simple testcase? Are you allowed to share the .o member from the .lib
file involved?
cheers,
DaveK