At Thu, 20 May 2004 12:53:54 +0400, Alexander Gordeyev wrote: > I participate in development some kind of Linux emulator under Windows. We > use Debian as packaging system in our project, because I'm reporting > straighit to you (as glibc guys reccomended). The bug (I beleive its the > bug) we met couldn't be reproduced under usual Linux kernels, so I provide > you with details. When I invoke almost any program, it killed by SEGV:
Cheers nice work :) > I've done some work and found the bug in $glibc-2.2.5\elf\dynamic-link.h, > _ELF_DYNAMIC_DO_RELOC macro: > > > struct { ElfW(Addr) start, size; int lazy; } ranges[2]; \ > ranges[0].lazy = 0; \ > ranges[0].size = ranges[1].size = 0; \ > ranges[0].start = 0; \ > \ > > As one can see, `ranges' array is allocated on stack and *not* initialized. > Its ok under native Linux, because just after `execve' system call, process > stack is always cleared and `ranges' always became filled by zeroes. But our > environment can not (should it?) guarantee stack contents, and ranges[1] got > unpredictable values. Well, just few lines later, in conditional branch > where ld combines sections, ranges[1].start and ranges[1].size are crap. You may get the different result with the latest glibc 2.3.2.ds1 instead of 2.2.5 old woody version. BTW, I wonder why you don't emulate such execve behavior? > So, I propose to fix _ELF_DYNAMIC_DO_RELOC macro and clear the`ranges' > variable (at least with undefined ELF_MACHINE_PLTREL_OVERLAP macro), since > virtually possible another architecture, where just-after-execve-stack is > not cleared. > > PS. If you not interested in this fix, please inform me. Thank you. Dynamic routine should always work fast. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]