Commit ce0981b0 authored by Ulrich Drepper's avatar Ulrich Drepper

Make match_so_flags a bit mre robust

I cannot say that I understand the purpose behind the match_so_flags
function.  Is it supposed to be an exhaustive check?  Just a quick
check?  Is it always required to find the DSO which would be used
by the current process?  Should there be an overwrite?

In any case, the current way seems to be wholly inadequate.  It
somehow assumes a specific order of the DSO in the list read from
the ld.so cache.  That's fragile at best.

In the case of one of my machines, I run a x86-64 process and try
to find a symbol in libc.  The first DSO returned in the cache
matching "libc.so" is /libx32/libc.so.6 (i.e., the x32 version of
libc).  Using the file works but the DSO is not used.

I assume the idea behind the short form "c" for the module name
is to use the DSO of the same type as the running process.  As is
all platforms not matching the listed 64-bit platforms are blindly
accepted.

I suggest at the very least to check for the case of the non-64-bit
DSO in the cache to check that the running program is also 32-bit.
This patch does this.

In the longer run a more robust check should be implemented which
compares the current process' ELF header with that of the found DSO.
If this is the desired direction let me know and I'll come up with
a patch.
parent 845d3636
...@@ -320,7 +320,7 @@ static bool match_so_flags(int flags) { ...@@ -320,7 +320,7 @@ static bool match_so_flags(int flags) {
return (sizeof(void *) == 8); return (sizeof(void *) == 8);
} }
return true; return sizeof(void *) == 4;
} }
static bool which_so_in_process(const char* libname, int pid, char* libpath) { static bool which_so_in_process(const char* libname, int pid, char* libpath) {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment