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: "Peter O'Gorman" <binutils at mlists dot thewrittenword dot com>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: "Peter O'Gorman" <pogma at thewrittenword dot com>, binutils at sourceware dot org
- Date: Tue, 14 Apr 2009 10:37:08 -0500
- Subject: Re: [PATCH-bfd] i386-mingw32-ld crash on x86_64 linux
- References: <20090414140549.GH25181@tw.il.thewrittenword.com> <49E49FF0.8030300@gmail.com>
On Tue, Apr 14, 2009 at 03:38:40PM +0100, Dave Korn wrote:
> 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.
Ugh :(
>
> + 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.
>
Later in the same function there is:
if (strcmp (sec->name, in->n_name) == 0)
So that would need to change to strncmp, with luck that is the only
place that expects n_name to be null terminated.
> 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.
Will look into this.
>
> Got a simple testcase?
No, it only fails for this one library.
> Are you allowed to share the .o member from the .lib
> file involved?
Afraid not.
Thanks for the reply, was extremely helpful.
Peter
--
Peter O'Gorman
pogma@thewrittenword.com