From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 59123385771F for ; Wed, 12 Jul 2023 22:33:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59123385771F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1b8b318c5cfso762195ad.1 for ; Wed, 12 Jul 2023 15:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689201231; x=1691793231; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Sn2rHLkmep76tl0iLLXiABGIOHMaOM7fYBBFZrQNgK0=; b=rwxyzCvsDWZnTRBEjgt5r9bPxLwiy/Nz9vp6ktTmp8NSgmuX8+P/K0Laa/0laeMQRo pExAAc5nGcZa46Jad3GvI31e3JUpMKwsxgcm9rrOFoRYuA19RGDbK8RdooXsdV4/ARWR +f4FvHaVirPIYgjE9ISKEa4dOJAnb7ogFG8O8bGbF6I4rpexg0MiTjh1tbZ0FXt9NrHv Ng0bPI0qk8vDmVNrrHHpTfbh15mr8RrG0m6tTzs7VsQqgdKnsmxkI9BJiRySb34kx0EI X8wE5Jt/pI+DMDvn57OqetDz35PcV1+K2wdiqSAmdATTJJJPIeFQp8GtNtzzuKrr/kjq epDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689201231; x=1691793231; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Sn2rHLkmep76tl0iLLXiABGIOHMaOM7fYBBFZrQNgK0=; b=asMbe5a7sPJcldPW318woobVHoBtpmMsoYjrxb68wOEG6Ku9s32N4WiZp8eV3aKP+W /059p4hxtbipamQEtYQb/Z3hA8V7+LEIrtM2FJCzlO4ik1TJ14tiHNT7y89frZpCHxLt NOEFgo8izPYKdFTh0NmmM4Qlqbj/xf4snDHkw6M5/i0PhS2PuNi9VNXa4gp5etySSV0m yAoNZ4nB5g/w4X7RHSilVn3dse955L3u30/+zySSqIcnLCij/g9X/oYRTjKYtrM5lWoX s2oqROVJOz3bSZeM5Pyn4kaeTY4jc727uW3NDw3iDulU2t26OEj/YWxSad9dtaZhj7C5 KE2w== X-Gm-Message-State: ABy/qLZ5J+RHJR78zykxOpuHQvkqstv7qPopBzDI8Noe6p9GmkDxeGSE Pl//7USOw0e3uJOjIr6ACh5jh6UmBF4= X-Google-Smtp-Source: APBJJlErPe6ynGgbvgOUx+5Sk2vEIuDuZmd0RB0HqVvOLX/c6oyKxzcKm0dty3rej+5w+gi650Q4PQ== X-Received: by 2002:a17:902:d4ce:b0:1b8:7e53:70f with SMTP id o14-20020a170902d4ce00b001b87e53070fmr25591194plg.27.1689201231326; Wed, 12 Jul 2023 15:33:51 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:e582:971b:6a6c:77a9]) by smtp.gmail.com with ESMTPSA id j13-20020a170902da8d00b001b3df3ae3f8sm4456094plx.281.2023.07.12.15.33.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jul 2023 15:33:50 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 370B81142581; Thu, 13 Jul 2023 08:03:48 +0930 (ACST) Date: Thu, 13 Jul 2023 08:03:48 +0930 From: Alan Modra To: jacob navia Cc: binutils@sourceware.org Subject: Re: SUSPICIOUS CODE Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-3026.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,SUBJ_ALL_CAPS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Wed, Jul 12, 2023 at 05:12:13PM +0200, jacob navia wrote: > Consider this code: > > 1202 static fragS * get_frag_for_reloc (fragS *last_frag, > 1203 const segment_info_type *seginfo, > 1204 const struct reloc_list *r) > 1205 { > 1206 fragS *f; > 1207 > 1208 for (f = last_frag; f != NULL; f = f->fr_next) > 1209 if (f->fr_address <= r->u.b.r.address > 1210 && r->u.b.r.address < f->fr_address + f->fr_fix) > 1211 return f; > 1212 > 1213 for (f = seginfo->frchainP->frch_root; f != NULL; f = f->fr_next) > 1214 if (f->fr_address <= r->u.b.r.address > 1215 && r->u.b.r.address < f->fr_address + f->fr_fix) > 1216 return f; > 1217 > 1218 for (f = seginfo->frchainP->frch_root; f != NULL; f = f->fr_next) > 1219 if (f->fr_address <= r->u.b.r.address > 1220 && r->u.b.r.address <= f->fr_address + f->fr_fix) > 1221 return f; > 1222 > 1223 as_bad_where (r->file, r->line, > 1224 _("reloc not within (fixed part of) section")); > 1225 return NULL; > 1226 } > > This function consists of 3 loops: 1208-1211, 1213 to 1216 and 1218 to 1221. > > Lines 1213 - 1216 are ALMOST identical to lines 1218 to 1221. The ONLY difference that I can see is that the less in line 1215 is replaced by a less equal in line 1220. > > But… why? > > This code is searching the fragment that contains a given address in between the start and end addresses of the frags in question, either in the fragment list given by last_frag or in the list given by seginfo. > > To know if a fragment is OK you should start with the given address and stop one memory address BEFORE the limit given by fr_address + f->fr_fix. That is what the first two loops are doing. The third loop repeats the second one and changes the less to less equal, so if fr_address+fr_fix is one MORE than the address it will still pass. > > Why it is doing that? Take out the third loop and run the testsuite. Does anything regress? > If that code is correct, it is obvious that we could merge the second and third loops and put a <= in t he second one and erase the third one… UNLESS priority should be given to matches that are less and not less equal, That is exactly what needs to happen. > what seems incomprehensible … to me. > > This change was introduced on Aug 18th 2011 by Mr Alan Modra with the rather terse comment: "(get_frag_for_reloc): New function. ». There are no further comments in the code at all. Yes, I'm responsible for lots of suspicious code, but this isn't the full history of get_frag_for_reloc. > This code is run after all relocations are fixed just before the software writes them out. The code is in file « write.c » in the gas directory. Note that this code runs through ALL relocations lists each time for EACH relocation, so it is quite expensive. In general the list data structure is not really optimal here but that is another story. The code does not run through all relocations, just those created with the .reloc directive. > Thanks in advance for your help. > > Jacob -- Alan Modra Australia Development Lab, IBM