From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id BA06E3852779 for ; Mon, 18 Jul 2022 14:34:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA06E3852779 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f52.google.com with SMTP id z12so17354417wrq.7 for ; Mon, 18 Jul 2022 07:34:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TMmsZsHCAzm1EC9DOy8Ao5BhWIjUUnEMCZIRVoDgaTM=; b=etITgJhYWVwmWjXC5LQdW7N7GmjPF8AjOkQ75L9LtQLe9tW8HVoErRvSdGcf6BAemn DOAPXnizw910bgvqYCPUcTC4tJKeddLH/n7u4UIJaJQNobsINdYurGr2/j93tNLqcTtz EGkxBov4ceFhnJrQYTlVXBPRsvSaczAUOViSTqnAVHlIca9kGBo9Osr9m49WXtRSAkgp T6Dze8y3K7pJgtJL+T/uNu+fjxmixREHQslCNqquh321LWQdpt+pZ4oyXX6tqsb5Putr /e2JWpO43aztP+AdUUzyYt+VHYrc8PNfvM8KZOSbZH9/zUCHNEiqVwhYitRjEeAaAe8U wqWA== X-Gm-Message-State: AJIora958zTQDj4P9jIpz6DXPe2Hwu4T0V2gVOA9RltlDMWyQcd9eGBc pZZqWYxv1E9kzAbnt+SKnyCU76PIL3M= X-Google-Smtp-Source: AGRyM1tli/7n2CCkucxNeUjqx1/UTIS+bLcqyBwXU96NGUs5pyB8VNW/XkmmaHmTNeiFBHirOaPa5g== X-Received: by 2002:adf:f345:0:b0:21d:6927:ec8f with SMTP id e5-20020adff345000000b0021d6927ec8fmr23265029wrp.490.1658154889592; Mon, 18 Jul 2022 07:34:49 -0700 (PDT) Received: from ?IPv6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id k21-20020a05600c1c9500b003a3187a2d4csm6103719wms.22.2022.07.18.07.34.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jul 2022 07:34:48 -0700 (PDT) Subject: Re: [PATCH][gdb/symtab] Fix out-of-bounds in objfile::section_offset To: Tom Tromey Cc: Tom de Vries , gdb-patches@sourceware.org References: <20220712080032.GA18344@delia.home> <98108218-5cc6-fab8-fe17-319d37e8cb39@suse.de> <53735898-5c00-1af6-c09a-7cc4622b64f7@palves.net> <87bktqnr3c.fsf@tromey.com> From: Pedro Alves Message-ID: Date: Mon, 18 Jul 2022 15:34:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87bktqnr3c.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2022 14:34:58 -0000 On 2022-07-15 7:55 p.m., Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> Another question is, why do the bfd sections grow in the first > Pedro> place? > > It does seem bad if this can happen randomly. If it can be done > intentionally though we could have gdb take whatever action is needed > when first reading the BFD to get the full section count. See Alan's reply here: https://lists.gnu.org/archive/html/bug-binutils/2022-07/msg00128.html His last sentence: "Hmm, I suppose you could argue that since this is done for the linker, there is no need to do so for simple_get_relocated_section_contents." ... suggests this could be fixed in bfd. I have no idea what that entails, but if it's just not doing something, then maybe it's simple enough? > > All this stuff with section indices only exists for the case where an > objfile is loaded using different offsets for different sections. Can > this really happen (aside from absolute sections)? If not maybe we > could just get rid of all of it. Given: add-symbol-file FILE [-s SECT-NAME SECT-ADDR]... ... I think that yes, it happens. Also, there are targets where shared libraries aren't really fully linked libraries, but instead relocatable objects (https://sourceware.org/gdb/current/onlinedocs/gdb/Library-List-Format.html), and for those, I don't think we can assume a single offset works for all sections. Even if we have fully linked binaries and segments, then it can be that different segments are loaded independently, with different bias offsets? That would mean different offsets for different sections too.