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/ |