From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) by sourceware.org (Postfix) with ESMTPS id 56426385840F for ; Fri, 12 Nov 2021 19:30:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56426385840F Received: by mail-vk1-xa2f.google.com with SMTP id m19so913609vko.12 for ; Fri, 12 Nov 2021 11:30:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=5ho+PNt5YqkX7IcSIlSDQwEtRErnUB2KN0ajLH+ZzTU=; b=SO4xp4Q/X/XIzmeOg3y5ctQwsHk6jzU9BnDzTRchRUpG/D9A7rPXLt+CUb7+zjpvow Qo6SLtzjW4xhBuRBpq8qgg1xRxy48HmxCvGGGTsmusan+5FAMfdzJViV6DLoW+VvZYHv 7MkEfKpOp6bsNVJ8HQXOeQMQISpYVeQN6u+1roqbVoLrc2GAwNjC7q1MEnWfrtsTExi+ ETHhD1HB2w5i/1G+H+yCGesABRvD/4ZxxvBY58xabNXbnxeIRAAziOQJa33XXzsplasU zLGp3vs3K9YrdlfgBK05sgNEwzsqBnwBJYKkVUBzwAWGUSfQwx6xi8tSElUg2BEmboMF ZHzw== X-Gm-Message-State: AOAM532F6PVpxn3L8Netw1xBd7rQGPiMm3N4JiWcC6ZNAKWMhnxWzZNa N5/0CdFcaKLkPPg0vjxN7+869w== X-Google-Smtp-Source: ABdhPJxhpqVXYjuyJxmCwdwR5eEwjZWtPK21Atq97R9aAIcPYOu74ndlpsIG5tKM9F1nyytvnkpMrA== X-Received: by 2002:a1f:b64e:: with SMTP id g75mr25132397vkf.13.1636745450814; Fri, 12 Nov 2021 11:30:50 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:55a:ec9e:6037:1db6:e51? ([2804:431:c7cb:55a:ec9e:6037:1db6:e51]) by smtp.gmail.com with ESMTPSA id f26sm4506813vkl.51.2021.11.12.11.30.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Nov 2021 11:30:50 -0800 (PST) Message-ID: <7b8b5f10-6880-0f3e-c2fd-a5c111b847c8@linaro.org> Date: Fri, 12 Nov 2021 16:30:48 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH v5 16/22] elf: Add main application on main_map l_name Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org, John Mellor-Crummey , Ben Woodard References: <20211109183347.2943786-1-adhemerval.zanella@linaro.org> <20211109183347.2943786-17-adhemerval.zanella@linaro.org> <87v90yyihb.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87v90yyihb.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 19:30:53 -0000 On 11/11/2021 09:39, Florian Weimer wrote: > * Adhemerval Zanella: > >> For the la_objopen() the path listed in link_map->l_name for the main >> application binary is empty, even though dladdr() is able to recover the >> correct path. >> >> By setting the expected application name on l_name, it allows to >> simplify the code to handle the special case and make the API that >> return such information (la_objopen(), dladdr() and dlinfo() to have >> similar semantic. > > _dl_argv[0] is not a path name. > > After “bash -c 'exec -a not-a-real-path cat'”, we have this: > > (gdb) print _dl_argv[0] > $1 = 0x7ffc1feaf3de "not-a-real-path" This is what program_invocation_name/__progname (initialized at __init_misc()) assumes. I think it is a fair assumption, since by convention the first string in argv on execve() is the filename associated with the file being executed. Also, if users really want something different to use as the program name they can use argv[0] which will be aligned in the various APIs. > > I think dladdr is wrong to use this as a path. I don't think so, glibc itself uses it in multiples places to get the program name and also exports program_invocation_name/program_invocation_short_name as GNU extensions. Another option would to read /proc/self/cmdline, but I don' think this would be really an improvement (and it is not easily override by the users). > > I think in practice l_name == "" means that the link map is for the main > executable. This seems particularly relevant given that the public part > of the link map does not expose lt_executable. This is one reason I consider to not expose this in the link_map, however I still think to align la_objopen(), dladdr() and dlinfo() seems to be a better QoI than asking users to check program_invocation_name.