[patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3

[Pedro Alves]

On 11/23/2012 04:12 PM, Mark Kettenis wrote:
>> Date: Fri, 23 Nov 2012 16:01:03 +0000
>> From: Pedro Alves <palves@redhat.com>
>>
>> This means that looking for relative path DSOs in the file system is
>> currently depending on GDB's current directory.
> 
> Yup, you lose.
> 
>> My favorite is opening a DSO symlink like we /proc/PID/exe.
> 
> That doesn't really help.  If you replace the DSO the symlink will
> point at the new one, not the one loaded by the executable.

No, no, no.   /proc/PID/exe is special.  It's kind of a hard link.   Opening it
opens the old,  before-replacement file.  E.g., try running a program, and
deleting its executable.  You can still open /proc/PID/exe, and it will
open the running program.

>cp /usr/bin/sleep sleep2

>./sleep2 1000&
[1] 26504
>bg
[1]+ ./sleep2 1000 &
>readlink -f /proc/26504/exe
/home/pedro/sleep2
>rm sleep2
>readlink -f /proc/26504/exe
/home/pedro/sleep2 (deleted)
>ls -l /proc/26504/exe
lrwxrwxrwx. 1 pedro pedro 0 Nov 23 16:20 /proc/26504/exe -> /home/pedro/sleep2 (deleted)
>size /proc/26504/exe
   text    data     bss     dec     hex filename
  21645    1200     384   23229    5abd /proc/26504/exe

Let's try replacing it, even:

>echo "hahaha" > sleep2
>size /proc/26504/exe
   text    data     bss     dec     hex filename
  21645    1200     384   23229    5abd /proc/26504/exe

-- 
Pedro Alves