From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 14D33385B834 for ; Mon, 30 Mar 2020 12:36:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 14D33385B834 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wr1-x42b.google.com with SMTP id j17so21336643wru.13 for ; Mon, 30 Mar 2020 05:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JF9E/AVHox6IyEw6KkpRiS4pZTc9/l54Hz7HpvitalE=; b=OG7/IOodp+Jquf0+kcBpqwg3kZygacEJwrhETZ7cotr8g4K1Hdg673YuPCfmQTJNle VRo3GPv1Q+qUTKlQSNoxfP32U8he/4S20hRwF7rw90Gq/9pF8+2SIx/4A252V/yzmADb hKh0Lz9FbItyanhLNfdmkSpojoOBTOEO1hDO96tUjSvTKQBP07UxgZhZuONDCVTwSTdW HSh3TpGhlokpw9AhBCG/RCscJoYK/Nm0D1nE/2P8aBoULLSaJcoRbPaPDH4QR2J2ccNv GdsybQ/KJOSap8eLC0h0zHDQ269ufteyfXGWwXWafflGaf7QBnEKsqUIMVY6t8OxlXKi Azyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JF9E/AVHox6IyEw6KkpRiS4pZTc9/l54Hz7HpvitalE=; b=tqNVEJccfojNtK/1WaTMyDrN8sGL/zRZSjHA7xMs80LAdGfoVjTcyFCCtfwYkoaoVl sEcXOOitNaoVg3LuzsuGEJsvQH/1AVsjBt3zjA50PBU86pLAMjQU1I4OSQ4ogOXUc+SS Am41K8zgBfEpqsOQdHe3JqbVMmZvzmXhofyh1EEU2TpL2zw0nGF4M7Ntw+peJVjHP3By nrs6tceMpe6dGdoq39C2JohOUoiFzkxHxpEJmvLQhoxXgOROWPoECZlAzT8QAydCmmFp W+ffGg8Y6uwMaL7mlz2wB+2XO5ZSiChMwubd206+68ldLxF37OI5Pg7kzqB1/2TtKdzD ghrw== X-Gm-Message-State: ANhLgQ08LERLfpMne6fGEd5pOwvKkD+YQaBVw1InGVCzLZnPb2Co3A38 oQKObfYd9uuN7+ansxo8stJsZA== X-Google-Smtp-Source: ADFU+vv6IMy1+aUetpIyuw9JqWSRO8Gxyaeuhgxc2fhxik53HgZlc79eKYnM609RXqpiKkWOuEKRLw== X-Received: by 2002:a5d:4ecf:: with SMTP id s15mr15589992wrv.302.1585571813148; Mon, 30 Mar 2020 05:36:53 -0700 (PDT) Received: from jozef-kubuntu ([2a01:4b00:87fd:900:781c:bb2c:3d2:4797]) by smtp.gmail.com with ESMTPSA id u13sm22143609wru.88.2020.03.30.05.36.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Mar 2020 05:36:52 -0700 (PDT) Date: Mon, 30 Mar 2020 13:36:50 +0100 From: Jozef Lawrynowicz To: Nick Clifton Cc: binutils@sourceware.org Subject: Re: PR 25562: New binutils testsuite failures Message-ID: <20200330133650.7e9dbdcd@jozef-kubuntu> In-Reply-To: References: <87a73yrx5b.fsf@redhat.com> <20200330131530.1df1291f@jozef-kubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 12:36:55 -0000 On Mon, 30 Mar 2020 13:26:53 +0100 Nick Clifton wrote: > Hi Jozef, > > > The test is working as expected, for those targets an objcopy of an executable > > is not creating an exact copy of the original file. > > Ah, OK. > > > For the PE targets the datestamp in the executable file is not being copied by > > objcopy. > > The old determinism problem. *sigh* We should probably just xfail these > targets since we know that the binaries can never be the same. I should clarify, the datestamp is actually just being reset completely to the epoch, rather than being set to the time of the objcopy. > > > For the MIPS targets, objcopy has added the names of output sections to the > > string table, where in the linked executable they were not in the string table. > > Where were the names stored then, if not in the string table ? Or did the > objcopy actually add new section symbols ? They're in .shstrab originally, but then the objcopy adds them to .strtab as well. Here's the readelf output (bintest is the original file): $ ../readelf -p .strtab -p .shstrtab bintest String dump of section '.strtab': [ 1] tmpdir/bintest.o [ 12] a [ 14] c [ 16] _start String dump of section '.shstrtab': [ 1] .symtab [ 9] .strtab [ 11] .shstrtab [ 1b] .data [ 21] .text [ 27] .MIPS.abiflags [ 36] .bss [ 3b] .reginfo [ 44] .gnu.attributes $ ../readelf -p .strtab -p .shstrtab copy String dump of section '.strtab': [ 1] .data [ 7] .text [ d] .MIPS.abiflags [ 1c] .bss [ 21] .reginfo [ 2a] .gnu.attributes [ 3a] tmpdir/bintest.o [ 4b] c [ 4d] _start String dump of section '.shstrtab': [ 1] .symtab [ 9] .strtab [ 11] .shstrtab [ 1b] .data [ 21] .text [ 27] .MIPS.abiflags [ 36] .bss [ 3b] .reginfo [ 44] .gnu.attributes This means that in the copied executable you can see the names of the SECTION type symbols in .symtab: $ ../readelf -s bintest Symbol table '.symtab' contains 11 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 SECTION LOCAL DEFAULT 1 2: 00001204 0 SECTION LOCAL DEFAULT 2 3: 00001208 0 SECTION LOCAL DEFAULT 3 4: 00000201 0 SECTION LOCAL DEFAULT 4 5: 00000000 0 SECTION LOCAL DEFAULT 5 6: 00000000 0 SECTION LOCAL DEFAULT 6 ............. snip ........ $ ../readelf -s copy Symbol table '.symtab' contains 11 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 SECTION LOCAL DEFAULT 1 .data 2: 00001204 0 SECTION LOCAL DEFAULT 2 .text 3: 00001208 0 SECTION LOCAL DEFAULT 3 .MIPS.abiflags 4: 00000201 0 SECTION LOCAL DEFAULT 4 .bss 5: 00000000 0 SECTION LOCAL DEFAULT 5 .reginfo 6: 00000000 0 SECTION LOCAL DEFAULT 6 .gnu.attributes ............... snip ............ > > This does sound like something that the MIPS maintainers ought to investigate > and decide whether it is a real bug or not. > > > I can file bugzillas for these if you would like. > > No, that should not be necessary. I will check in an update for the PE targets > once I have tested it locally. Ok sounds good, thanks. Jozef > > Cheers > Nick > >