This is the mail archive of the
mailing list for the glibc project.
Re: ping: [patchv2] Fix vDSO l_name for GDB's: Can't read pathname for load map: Input/output error.
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 7 Nov 2013 19:54:29 +0100
- Subject: Re: ping: [patchv2] Fix vDSO l_name for GDB's: Can't read pathname for load map: Input/output error.
- Authentication-results: sourceware.org; auth=none
- References: <20131107160926 dot GA15404 at host2 dot jankratochvil dot net> <527BCC14 dot 7060202 at redhat dot com>
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?
> * dlopen of ""?
> * 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:
# /* 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);
# 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?
> * 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 <firstname.lastname@example.org>
> 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.