Re: ping: [patchv2] Fix vDSO l_name for GDB's: Can't read pathname for load map: Input/output error.

[Jan Kratochvil <jan dot kratochvil 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?
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