This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


This seems like a kludge to gain a half-measure, and not going about the
real issue the right ways at all.

> GDB currently always prints on loading a core file:
> 	warning: Can't read pathname for load map: Input/output error.

This is poor behavior on GDB's part in multiple respects.  Firstly,
"Input/output error" (i.e. strerror (EIO)) may be as much information as
you have when the underlying failure comes from a ptrace call, but it's
sure not descriptive on the real situation here.  The situation is that the
core file's phdrs indicate that the inferior memory address in question a
valid address but that the contents for it are not available.  When that's
the situation, it would sure more helpful to a GDB user if GDB said so
clearly, because it certainly knows perfectly well.

Next, when the memory access that can't be done is one done automatically
by another layer of GDB, that other layer really ought to be informed of
the real situation and adapt to it appropriately rather than just passing
up an error message about the implicit memory access.  Here the underlying
failure is not any kind of unexpected mystery, it's just that the core file
doesn't have that information.  So the layer that is automatically
determining what symbol file names it can turn up can simply report that it
couldn't turn one up.

You seem to be concerned only with the cases where the information that
might be in the core file but doesn't happen to be is not actually
informative, i.e. the string you'd find is empty and so you'd just ignore
it anyway.  You should have the very same situation in the common case of
DT_NEEDED objects where l_name is an address in someone's .dynstr (text),
which won't likely be dumped either.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]