Messages in this thread | | | Subject | Re: MIPS: bug: gettimeofday syscall broken on CI20 board | From | Vincenzo Frascino <> | Date | Thu, 28 Nov 2019 14:01:01 +0000 |
| |
On 28/11/2019 13:48, H. Nikolaus Schaller wrote: > >> Am 28.11.2019 um 14:29 schrieb Maarten ter Huurne <maarten@treewalker.org>: >> >> On Thursday, 28 November 2019 13:33:17 CET H. Nikolaus Schaller wrote: >>> Hi Vincenzo, >>> >>>> Am 28.11.2019 um 13:21 schrieb Vincenzo Frascino >>>> <vincenzo.frascino@arm.com>:> >>>> [...] >>>> The the lib that provides the gettimeofday() changes accordingly >>>> with vdso_data. 5.4 and 4.19 have 2 different vdso libraries as >>>> well. >>> >>> Yes, that is what I have assumed what happens. How do these libs go >>> into an existing and working root-file-system with Debian Stretch? >> >> I'm a novice when it comes to vDSO, so someone please correct me if I'm >> wrong. >> >> From what I read vDSO is a library in the sense that it exports ELF >> symbols that applications and other libraries (libc in particular) can >> use, but it is not a file on disk. > > Ah, ok. This would mean that the libc providing the gettimeofday() > should be able to find out a modified changed vdso_data format by > inspecting these ELF symbols. >
I agree with Maarten here. There is a discovery mechanism in the libc based on AT_SYSINFO_EHDR. This contains the address at which the vdso library is mapped by the kernel to the userspace process.
>> >> As such, which rootfs you use shouldn't matter, since the vDSO is not in >> the rootfs. Instead, it is contained in the kernel image. Searching for >> "linux-vdso.so.1" on packages.debian.org indeed returns no hits. >> >> There is a check in arch/mips/vdso/Makefile that disables vDSO on MIPS >> when building the kernel with binutils < 2.25. I don't know if that is >> in any way related to this issue. > > What still does not fit into the picture is the errno = 1 i.e. EPERM. > Maybe I have to study the libc code that tries to read the ELF symbols > you have mentioned. It may fail for unknown reasons. >
This is what I was going to suggest next. It might be that something is not working there.
Let us know your findings.
> BR and thanks, > Nikolaus >
-- Regards, Vincenzo [unhandled content-type:application/pgp-keys] | |