|
From: Tom H. <th...@cy...> - 2003-05-12 07:24:31
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Er, yes. There's definitely some still wrong with errno handling
> on both my glibc-2.3.2 systems. The attached test program I made
> doesn't work properly -- the perror calls print different stuff when
> running on V. I'll look into it more tomorrow night. The strange
> thing is the numbers returned by the errno uses are right, it's just
> that when perror reads errno it gets junk.
The errno handling in glibc 2.3.2 is horrible. Some of the routines
in the library don't go through the procedure linkage table when they
call the helper function that gets the address of the current thread's
errno, so they always get glibc's version of that routine instead of
the one that you have tried to replace it with.
This works normally because libpthread calls __libc_pthread_init at
startup and gives it a descriptor block which includes a function
pointer which glibc uses to find the thread descriptor and hence the
errno to use, but if you don't call that function, and if your thread
descriptor don't match the real libpthread ones, then it all falls
apart.
This is why wine now deliberately writes a jmp instruction over the
first instruction of glibc's internal errno address getting routine
so that it guarantee to get control at that point...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|