Binutils objcopy bug (was Re: rebase segfault)

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Jan 16 08:15, marco atzeri wrote:
> On 1/15/2013 11:03 PM, marco atzeri wrote:
> >On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
> >>On Jan 15 11:36, marco atzeri wrote:
> >>>On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
> >>>>  The segfault occurs as soon as one
> >>>>entry translates into a memory address which is beyond the committed
> >>>>area of the file memory map.
> >>>>[...]
> [...]
> it seems only a symptom, also using that, I have still one
> rebase segfault more crazy than before.
> (ltree.dll is fine now)

This is not really the case, you just don't see it anymore.  As I wrote
in my first reply, what happens is that the relocation information
points outside of the file map.  The below effect on dict_snowball.dll
shows what's going wrong.

> $ rebase -O dict_snowball.dll
> Segmentation fault (core dumped)
> 
> It segfaults and a spurious character appears on the section:
> 
> $ objdump -h dict_snowball.dll
> 
> dict_snowball.dll:     file format pei-i386
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00016808  4e971000  4e971000  00000400  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>   1 .data         00017180  4e988000  4e988000  00016e00  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          000000f8  4e9a0000  4e9a0000  00000000  2**5
>                   ALLOC
>   3 .edata        00000fe0  4e9a1000  4e9a1000  0002e000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .idata        000003e0  4e9a2000  4e9a2000  0002f000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   5 .reloc        0000765c  4e9a3000  4e9a3000  0002f400  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   6 .gnu_debuglinkâ–’ 0000001c  4e9ab000  4e9ab000  00036c00  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
> 
> but the second time it works
> $ rebase -O dict_snowball.dll

It only works because the file isn't rebased at all since, apparently,
it already has been rebased, so the file is left alone.

> So it is now a rebase bug, a objcopy bug or both ?

As far as I can tell it's an objcopy bug.

The stripped version of the DLL has a normal relocation information
which at one point ends in a NULL IMAGE_BASE_RELOCATION record, as
expected.  After calling `objcopy --add-gnu-debuglink', the relocation
information is supposed to be the same as before, since the relocatable
file content didn't change.

Nevertheless, when stepping through the relocator code in rebase, it
turns out that the former NULL IMAGE_BASE_RELOCATION record does not
contain only 0 values anymore.  Rather, it has been overwritten with
some random(?) non-0 values, which rebase correctly interprets as the
start of the next IMAGE_BASE_RELOCATION array.  So rebase blunders
along, thus either just SEGVing, if everything goes well, or, worst
case, overwriting formerly correct information in the file with
arbitrary data.

This is a serious bug in objcopy in the current binutils.  Given that
cygport creates the debug info automatically, we might end up with
spuriously broken DLLs in the distro.

I checked with objcopy from the older binutils 2.51.53-2, and the
problem did not show up.  I also built the latest binutils release
2.23.1 and the problem also doesn't show, so we probably can get away
with just a black eye by updating binutils to 2.23.1.  Chris?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple