Mail Archives: cygwin/2013/01/16/07:35:46
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
- Raw text -