tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fixing $ORGIN RPATHs - at least some of them



On 07.11.2017 18:50, Christos Zoulas wrote:
> In article <81dc9d96-1d6a-9293-aa26-c5b92139d99b%gmx.com@localhost>,
> Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 07.11.2017 15:47, Christos Zoulas wrote:
>>> On Nov 7,  1:19am, n54%gmx.com@localhost (Kamil Rytarowski) wrote:
>>> -- Subject: Re: Fixing $ORGIN RPATHs - at least some of them
>>>
>>> | For the program name we could reuse this new variable.
>>> | 
>>> | $ cat /proc/curproc/maps|head -3
>>> | 0000000035400000-0000000035402000 r-xp 0000000000000000 00:00 91906
>>> |                         /bin/cat
>>> | 0000000035602000-0000000035603000 r--p 0000000000002000 00:00 91906
>>> |                         /bin/cat
>>> | 0000000035603000-0000000035604000 rw-p 0000000000000000 00:00 0
>>> | 
>>> | If the variable is problematic in the given environment, we get errors.
>>>
>>> This is a very complicated way to get the program name (but the process
>>> maps). The maps are useful for other things...
>>>
>>> | I mean code like this:
>>> | 
>>> | http://netbsd.org/~kamil/execpath.c
>>> | 
>>> | In the current implementation I'm getting the following questionable result:
>>> | 
>>> | $ sudo ./a.out
>>> | cwd='/'
>>> | execname='/tmp/a.out'
>>> | Cannot stat '/tmp/a.out'
>>>
>>> Yes, this is a very special case and if we fix it, it can actually
>>> fail if you chroot in a tree that's outside the tree the original
>>> executable was executed from. Nevertheless, while it can be fixed,
>>> we have bigger fish to fry.
>>>
>>> christos
>>>
>>
>> Right, if we fix now the correct resolution of programs with hardlink,
>> it will be already a big step forwards! The rest of use-cases can be
>> fixed later.
> 
> You mean use a hardlink in /proc/pid/exe instead of a symlink?
> 

I mean that a program can exist as two or more files, like:

/sbin/dump
/sbin/rdump

Some software (for example in LLVM) require to return the exact executed
program, not a random executable based on an inode value. Right now LLVM
is guessing program exec name on NetBSD reading argv[0], as the
sysctl(2) version wasn't reliable.


> christos
> 


Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index