From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6A5703858D1E for ; Wed, 29 Mar 2023 14:35:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A5703858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680100540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dbuEWicRZVYyBAoF+beKKSgVe9h3CsToon5qb4EKU7E=; b=VYuy7HNMJPuY5W4EglslfhPEERsaXhCJ4qz9ZQS703JGW9DvtLlrAkvOTmrl1wXeIQk9FI 33041i6kC+75MFHjOp9oUuCuAlUfeqvPSceS4VAp5jGzakqnxZMmQMgiq3gYTkLXMN/2Jt qfn/qLTJELNJHhsPLnHRehuzkIK2CEI= Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-529-n6s_445FMaK05jHsKkaAHw-1; Wed, 29 Mar 2023 10:35:38 -0400 X-MC-Unique: n6s_445FMaK05jHsKkaAHw-1 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-545d027103eso114099537b3.5 for ; Wed, 29 Mar 2023 07:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680100537; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dbuEWicRZVYyBAoF+beKKSgVe9h3CsToon5qb4EKU7E=; b=6DjzPXatVQs6YcZKmf67pUVHKJmdAj9jH/7/MJCbja1RLhFljmEtPVXcHaZY/vbknY Ug1cVgtBEJiS0iWdjiy9UPAHeTDoPlTuAS/GvK0lMDMpS565rckCk3nsa3CJmM437QHV h4SAUx4jL0B1ZbkTfGikrGilIamTOpHrQ2Ttcj1u9+hW3wkHYNNZJemcU6RmGWvuWKHr Q5kGUmBFm9zyTTPhyVmTc0lnRPwf/jxEOWR8/E/5wPM/1qHGgPRpiCvVXG+/008h0GsJ Y9AJrUcOXVOYGZzrm46r6cnlOo+gWsyds9shdXFsgVmAH5oSIdpfZAoSYMKl+3PW6hB2 f4vA== X-Gm-Message-State: AAQBX9e2YAKQUaITw2JMzXas9W9IbbeRymqXIUzpPCOFyj7rOaf/v4+t Gqf4eHLrEZkzKGdniMpRvoywXd0DCBCGgsGfAjf+Fr6YeXMOzgL58HFqibbFEamdOOmMqSc2IIu D883Z0SaTIv6KSwjvXcB7FDcTd2yu X-Received: by 2002:a25:ac5c:0:b0:b3b:a48c:b241 with SMTP id r28-20020a25ac5c000000b00b3ba48cb241mr21451718ybd.31.1680100537741; Wed, 29 Mar 2023 07:35:37 -0700 (PDT) X-Google-Smtp-Source: AKy350ZFM/N32GugOtNrIQW3QOzbzIV8K8uLfn6hZHboOAHRyyW44F3E8TE/dn8paIibnTuNMl38Lw== X-Received: by 2002:a25:ac5c:0:b0:b3b:a48c:b241 with SMTP id r28-20020a25ac5c000000b00b3ba48cb241mr21451698ybd.31.1680100537422; Wed, 29 Mar 2023 07:35:37 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id f185-20020a256ac2000000b00b7e0d092f91sm630939ybc.18.2023.03.29.07.35.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 07:35:37 -0700 (PDT) Message-ID: Date: Wed, 29 Mar 2023 10:35:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 12/13] dlfcn,elf: implement dlmem() [BZ #11767] To: stsp , Jonathon Anderson , libc-alpha@sourceware.org References: <20230318165110.3672749-1-stsp2@yandex.ru> <20230318165110.3672749-13-stsp2@yandex.ru> <3541bbd7-8a68-2064-bb63-2a921cfe3bb1@yandex.ru> <630fa17528c6050d60f524aa88ad5a057cae1603.camel@rice.edu> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/29/23 10:20, stsp wrote: > > 29.03.2023 19:10, Jonathon Anderson пишет: >> Stas, >> >> Please do some research into the ELF file format. Neither your fdlopen implementation in the test cases nor your dlopen_with_offset implementation in the email chain implement it correctly. >> >> AFAICT, the first glaring issue with both of your implementations is that you have neglected the case where p_offset != p_vaddr, i.e. a segment is mmapped to a different location than its layout in the file. There are a LOT of binaries out in the wild where this is the case. Here's a quick one-liner to help you find some on your own box, I have 11712 such binaries on my Debian system: > > Sure as hell p_offset != p_vaddr. > I never ever assumed it does! > OK, if it goes that badly, then I offer you > a deal. > If you present the solib with p_offset!=p_vaddr > and demonstrate that its broken with dlmem(), > and not because some random bug of mine but > exactly because p_offset!=p_vaddr, then I go > away from that dlmem() proposal forever. The fact that such binaries can be created is enough for me to raise a sustained objection to the inclusion of dlmem(). In glibc, and in ISO C, we deal in the slightly more abstract realm of allowing developers to do as they wish within the boundaries of the semantics we support. We do put some limits on what can be done from a practical QoI perspective, but we try not be overly proscriptive. > If you can't, then you go away. > Do you accept that challenge? Asking a developer to go away not the way consensus is built. Jonathan is a scarce and precious resource, they are users that are actively using LD_AUDIT interfaces for real work with hpctoolkit and so are perfeclty positioned to provide us with useful feedback. Please be kind to Jonathan. > Sorry for offering the silly stuff, but I simply > don't see how to proceed if we are wasting > the time on a things like that. If consensus can't be reached then the API will not be included in glibc. The real issue for me is that we are not providing a way for developers to manage the complexity of the *setup* that is required before dlmem() can operate reliably. This is why I don't accept dlmem() as the right level of abstraciton. It may solve you problem, but in glibc we need to do more than solve singular problems, we need to provide interfaces that are useful for many developers and the interfaces should be designed such that they cannot be easily misused. -- Cheers, Carlos.