From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id D16033858289 for ; Wed, 29 Mar 2023 14:31:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D16033858289 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x231.google.com with SMTP id bk5so11703208oib.6 for ; Wed, 29 Mar 2023 07:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680100303; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bC+oRs8BKUJDwdcyAvVHulF1FLOsptJ/20EuoFfl2CM=; b=cJBUj72mgMnhNGSw7IvgLuh/4bxqeTQNECqqIk8WjfmgxNdlRn4JUcwBB2W58V0tvc XKW6peudEZfz2MT1BSzdzMLGQjqtUS276aamj9rjJbqU6JCgfv6FtMLMgMO0a8J7y8fA pDJJM7lJdlYuNuXG3xRbk6SPnOHwZJ9NI96QJ1DW9xFAkx1IFsZ0Ia/kAIi2D1Y1DgpT I+g0scppZ6nXNinNa9vxx7Ws/VJ6yAE03oo/+wYJPHGSR4uMb3gEojzNHVxlJDwGF/9l QSQZ7v97BmMB6mKLECrWDnYfT9kowWYFLPtOdc66upqlhpQ4SMY3I281oC0uqLoRaMvC qjXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680100303; 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=bC+oRs8BKUJDwdcyAvVHulF1FLOsptJ/20EuoFfl2CM=; b=ozFapwYvpf2qoxQkchYki7X+ejHAhg3e3Rab20HOpIz9C08I8qhQpTX1F+YnV+GlLx M9mK05OVk5cEzJhRyt1nrBiq0fs9B7ubmSKU8FWAeHOLx4vxzzTAlNYG7Mnn0yHDHfVn wmAN3NafrTKBP9IOnkdlBGSKjxdN3ftZbDdrCnUhzgB9yuXfC5hjSB8N6QimpM39jBFH CP4Zv3/DWfVj609GBQC2DmRR2WUH31FhkJiOTmachVShi1rvK+hLRLEhg5HJFsf2sOZd T/6K2hE6JKYAzJnmz8U5HvJA+rohm6rP49577lwGPU7gv+Jnzm4ErUapNGGMBiTf8mg9 dcFA== X-Gm-Message-State: AAQBX9c82igaXV6WNfZTZqJHU6ST3HLDBxVG4CoRjUMFeBj10ir5e009 /+fcsVan3mg7PwE3kXzGmy2nlQ== X-Google-Smtp-Source: AKy350Y237ydYOqCStq0nlWW5H+Insaoz5IFem/dsaJ7hdAuOQEFS5rMiSEtMDhiugw3yCznOVMBxw== X-Received: by 2002:a05:6808:1aa9:b0:389:6b98:32db with SMTP id bm41-20020a0568081aa900b003896b9832dbmr311588oib.14.1680100303094; Wed, 29 Mar 2023 07:31:43 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761? ([2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761]) by smtp.gmail.com with ESMTPSA id q10-20020a4a88ca000000b0052a32a952e9sm13731545ooh.48.2023.03.29.07.31.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 07:31:42 -0700 (PDT) Message-ID: Date: Wed, 29 Mar 2023 11:31:39 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 12/13] dlfcn,elf: implement dlmem() [BZ #11767] Content-Language: en-US To: stsp , Jonathon Anderson , Carlos O'Donell , 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: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,BODY_8BITS,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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 29/03/23 11:20, stsp via Libc-alpha 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. > If you can't, then you go away. > Do you accept that challenge? > 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. > This should be other way around since you are the one proposing a new interface and thus should make sure that potential raised concerns indeed does not affect it. Also, I would like to ask to tune down your tone. This kind of aggressive way to present technical topics, in a manner of adding 'challengers' to put pressure on person that raised concerns is not best way and usually make other developers to avoid engage further in the topic.