|
From: Julian S. <js...@ac...> - 2009-08-25 14:21:50
|
On Tuesday 25 August 2009 04:07:54 pm Tom Hughes wrote: > On 25/08/09 15:01, Julian Seward wrote: > >> Yes. glibc no longer defines a symbol 'strlen' with type STT_FUNC. > >> Instead the symbol is 'strlen' with type STT_IFUNC. > >> So the name has the wrong "flavour" as far as get_elf_symbol_info > >> (coregrind/m_debuginfo/readelf.c; etc.) is concerned. > > > > So then we just need to ensure that the elf symbol reader accepts > > STT_IFUNC symbols and everything will work as before. Right? > > Not exactly - an STT_IFUNC symbol for strlen will be expected to point > at the address of a routine that returns the address of the real strlen > routine, rather than pointing directly at the address of a strlen routine. So we'd have to intercept calls to the the STT_IFUNC version of strlen, and get them to return the address of our own strlen implementation. Yes? That's pretty sucky. I wonder if there's a cleaner way to do it. (thinks more ..) So there are N different versions of strlen selected at run time, not just one. So why can't we simply intercept calls to all of them? We don't care which one ld.so would actually have selected. JJ, can you help us out here? Do you have a plan for fixing this for Valgrind on F12 ? J |