ping: [patchv2] Fix vDSO l_name for GDB's: Can't read pathname for load map: Input/output error.
Jan Kratochvil
jan.kratochvil@redhat.com
Thu Nov 7 18:55:00 GMT 2013
On Thu, 07 Nov 2013 18:21:24 +0100, Carlos O'Donell wrote:
> Under what conditions do we have L_NAME pointing to an empty string?
> * ld.so only?
no
> * dlopen of ""?
no
> * Is it possible with other libraries?
I do not think so.
It was in the original mail post:
# This condition gets applied for these callers:
# elf/rtld.c:dl_main():1128:
# /* Create a link_map for the executable itself.
# This will be what dlopen on "" returns. */
# main_map = _dl_new_object ((char *) "", "", lt_executable, NULL,
# __RTLD_OPENEXEC, LM_ID_BASE);
# elf/setup-vdso.h:setup_vdso():32:
# struct link_map *l = _dl_new_object ((char *) "", "", lt_library, NULL,
# 0, LM_ID_BASE);
It was happening for vDSO in the past but currently L_NAME gets replaced later
in the code. So nowadays it happens in practice only for the main executable.
> Why does that imply the empty string is on a read-only page?
Because the code uses '(char *) ""' which points into ld.so .rodata section.
> * Is this something that always happens?
Yes.
> * Is this something that only happens with ld.so?
I do not understand this question. 'ld.so' is related to this problem only by
the fact that the read-only page belongs to the mapped ld.so binary. But it
is unrelated for the link_map entry for ld.so.
> Does the entire glibc testsuite pass after this change?
> * It might change the output of LD_DEBUG=all?
> * It might change the output of sotruss-lib used for testing?
Primarily I do not see how it could change anything (besides the GDB core file
load). It is still "" even after the patch. Just that "" is located
elsewhere. IIRC I was doing the testing, such as verifying rpmbuild output
(rpmbuild runs the testsuite) so I am reluctant to set it up and run again.
Do you have some suspection what could cause any problems?
> Do other tools run OK after this change?
> * Valgrind has no problems?
> * gdb itself has no problems? (I assume it doesn't)
> * ldd shows now difference? (Related to LD_DEBUG=all above, but in trace mode)
IIRC I was running mock chroot with that patched glibc and I primarily tested
GDB is happy. As written above I cannot imagine how any tool besides GDB
loading a core file could find a difference.
Sure regressions happen in unpredictable way but this is why you do the
qualified review, why regular regression tests happen and why there are
development vs. stable branches.
> > 2013-08-20 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Update date.
I will sure update the date upon check in but I find correct to state this
patch was written in this form on this date for the posting purposes.
> > Fix reading link map from a core file by debugger.
>
> Move to commit message.
OK.
Thanks,
Jan
More information about the Libc-alpha
mailing list