From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 07184385BF83 for ; Tue, 7 Apr 2020 10:07:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 07184385BF83 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-wrHcHTX8N1uTz_PhVoaWLQ-1; Tue, 07 Apr 2020 06:07:01 -0400 X-MC-Unique: wrHcHTX8N1uTz_PhVoaWLQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3E30313F9; Tue, 7 Apr 2020 10:07:00 +0000 (UTC) Received: from [10.36.114.22] (ovpn-114-22.ams2.redhat.com [10.36.114.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 833095C28E; Tue, 7 Apr 2020 10:06:59 +0000 (UTC) To: Stephen Casner Cc: binutils@sourceware.org References: From: Nick Clifton Autocrypt: addr=nickc@redhat.com; prefer-encrypt=mutual; keydata= mQINBFm/2cUBEADkvRqMWfAryJ52T4J/640Av5cam9ojdFih9MjcX7QWFxIzJfTFYq2z+nb4 omdfZosdCJL2zGcn6C0AxpHNvxR9HMDkEyFHKrjDh4xWU+pH4z9azQEqJh331X7UzbZldqQo 16VkuVavgsTJaHcXm+nGIBTcUbl2oiTtHhmuaYxx6JTMcFjC7vyO5mLBw78wt52HBYweJ0Nj HBvvH/JxbAAULSPRUC61K0exlO49VFbFETQNG1hZTKEji95fPbre7PpXQ0ewQShUgttEE/J3 UA4jYaF9lOcZgUzbA27xTV//KomP0D30yr4e4EJEJYYNKa3hofTEHDXeeNgM25tprhBUMdbV RZpf2Keuk2uDVwc+EiOVri48rb1NU+60sOXvoGO6Ks81+mhAGmrBrlgLhAp8K1HPHI4MG4gH nrMqX2rEGUGRPFjC3qqVVlPm8H05PnosNqDLQ1Pf7C0pVgsCx6hKQB7Y1qBui7aoj9zeFaQg pYef+CEERIKEcWwrjaOJwK3pi9HFdxS0NNWYZj8HPzz/AsgTTQdsbulPlVq2SsctmOnL42CZ OCTppGYwl53CG/EqVY+UQBzFzJBaY8TJRFFYVEy5/HH4H11rMoZwqIkk71EOGU3X6mWlANRi kR3M4GhVITRzuaV69Fed+OeXcCmP94ASLfuhBR2uynmcHpBKpwARAQABtDtOaWNrIENsaWZ0 b24gKENoaWVmIEJpbnV0aWxzIE1haW50YWluZXIpIDxuaWNrY0ByZWRoYXQuY29tPokCOAQT AQIAIgUCWb/ZxQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQE/zvid2ePE9cOxAA 3cX1bdDaTFttTqukdPXLCtD2aNwJos4vB4LYPSgugLkYaHIQH9d1NQPhS0TlUeovnFNESLaV soihv0YmBUCyL4jE52FRoTjE6fUhYkFNqIWN2HYwkVrSap2UUJFquRVoVbPkbSup8P+D8eyd BbdxsY6f+5E8Rtz5ibVnPZTib7CyqnFokJITWjzGdIP0Gn+JWVa6jtHTImWx1MtqiuVRDapU hrIoUIjf98HQn9/N5ylEFYQTw7tzaJNWeGUoGYS8+8n/0sNbuYQUU/zwMVY9wpJcrXaas6yZ XGpF/tua59t9LFCct+07YAUSWyaBXqBW3PKQz7QP+oE8yje91XrhOQam04eJhPIBLO88g6/U rdKaY7evBB8bJ76Zpn1yqsYOXwAxifD0gDcRTQcB2s5MYXYmizn2GoUm1MnCJeAfQCi/YMob R+c8xEEkRU83Tnnw3pmAbRU6OcPihEFuK/+SOMKIuV1QWmjkbAr4g9XeXvaN+TRJ9Hl/k1k/ sj+uOfyGIaFzM/fpaLmFk8vHeej4i2/C6cL4mnahwYBDHAfHO65ZUIBAssdA6AeJ+PGsYeYh qs6zkpaA2b0wT4f9s7BPSqi0Veky8bUYYY7WpjzDcHnj1gEeIU55EhOQ42dnEfv7WrIAXanO P8SjhgqAUkb3R88azZCpEMTHiCE4bFxzOmi5Ag0EWb/ZxQEQALaJE/3u23rTvPLkitaTJFqK kwPVylzkwmKdvd2qeEFk1qys2J3tACTMyYVnYTSXy5EJH2zJyhUfLnhLp8jJZF4oU5QehOaJ PcMmzI/CZS1AmH+jnm6pukdZAowTzJyt4IKSapr+7mxcxX1YQ2XewMnFYpLkAA2dHaChLSU/ EHJXe3+O4DgEURTFMa3SRN/J4GNMBacKXnMSSYylI5DcIOZ/v0IGa5MAXHrP1Hwm1rBmloIc gmzexczBf+IcWgCLThyFPffv+2pfLK1XaS82OzBC7fS01pB/eDOkjQuKy16sKZX6Rt57vud4 0uE5a0lpyItC2P7u7QWL4yT5pMF+oS8bm3YWgEntV380RyZpqgJGZTZLNq2T4ZgfiaueEV4J zOnG2/QRGjOUrNQaYzKy5V127CTnRg4BYF/uLEmizLcI3O3U1+mEz6h48wkAojO1B6AZ8Lm+ JuxOW5ouGcrkTEuIG56GcDwMWS/Pw/vNsDyNmOCjy9eEKWJgmMmLaq59HpfTd8IOeaYyuAQH AsYt/zzKy0giMgjhCQtuc99E4nQE9KZ44DKsnqRabK9s3zYE3PIkCFIEZcUiJXSXWWOIdJ43 j+YyFHU5hqXfECM6rzKGBeBUGTzyWcOX6YwRM4LzQDVJwYG8cVfth+v4/ImcXR43D4WVxxBE AjKag02b+1yfABEBAAGJAh8EGAECAAkFAlm/2cUCGwwACgkQE/zvid2ePE/dqQ/6ApUwgsZz tps0MOdRddjPwz44pWXS5MG45irMQXELGQyxkrafc8lwHeABYstoK8dpopTcJGE3dZGL3JNz 1YWxQ5AV4uyqBn5N8RubcA8NzR6DQP+OGPIwzMketvVC/cbbKDZqf0uTDy3jP65OFhSkTEIy nYv1Mb4JJl3Sq+haUbfWLAV5nboSuHmiZE6Bz2+TjdoVkNwHBfpqxu6MlWka+P98SUcmY8iV hPy9QC1XFOGdFDFf1kYgHW27mFwds35NQhNARgftAVz9FZXruW6tFIIfisjr3rVjD9R8VgL7 l5vMr9ylOFpepnI6+wd2X1566HW7F1Zw1DIrY2NHL7kL5635bHrJY4n7o/n7Elk/Ca/MAqzd IZxz6orfXeImsqZ6ODn4Y47PToS3Tr3bMNN9N6tmOPQZkJGHDBExbhAi/Jp8fpWxMmpVCUl6 c85cOBCR4s8tZsvGYOjR3CvqKrX4bb8GElrhOvAJa6DdmZXc7AyoVMaTvhpq3gJYKmC64oqt 7zwIHwaCxTbP6C6oUp9ENRV7nHnXN3BlvIgCo4QEs6HkDzkmgYlCEOKBiDyVMSkPDZdsspa+ K4GlU2Swi/BDJMjtDxyo+K0M81LXXxOeRfEIfPtZ3ddxBKPva1uSsuz+pbN9d1JY8Ko5T/h1 6susi2ReUyNJEJaSnjO5z13TQ1U= Organization: Red Hat Subject: Re: Proposed changes for pdp11 --*magic options Message-ID: <92659b6c-bc7b-6c60-4865-b60b39e934b0@redhat.com> Date: Tue, 7 Apr 2020 11:06:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, 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: Tue, 07 Apr 2020 10:07:04 -0000 Hi Stephen, > You detected that my patch for PR 25677 exposed an additional > testsuite failure beyond those that were seen previously. Is the set > of expected failures recorded somewhere, or is that just a comparison > that you make locally with before-and-after builds? Sorry - it is just a local comparison. > Shouldn't those > tests be marked with xfail: pdp11-*-* instead? Or perhaps you've left > them as unexpected errors as a TODO to resolve why they occur? Exactly. I am fairly confident that most of them can be XFAILed, but I prefer to add a comment explaining why the XFAIL is there, and for that I need to understand the reason for the failure. (Actually, since I am not a PDP11 expert, I am hoping that somebody else will do this for me...) =20 > ERROR: /Users/casner/epos/binutils/binutils-gdb/ld/testsuite/ld-misc/star= t.s: assembly failed > The assembler error is "Can not represent BFD_RELOC_32 relocation in > this object file format". That occurs on the source line: >=20 > =09.long foo >=20 > where foo is an address label that needs to be relocated. This error > can be easily avoided and allow the test to pass by replacing .long > with .word or .dc.a so the relocation fits the 16-bit address for > pdp11. Would that cause a problem for any other targets? Using .dc.a should work for all targets, so that is what I would recommend. > FAIL: ld-scripts/default-script1 > FAIL: ld-scripts/default-script2 > FAIL: ld-scripts/default-script3 > FAIL: ld-scripts/default-script4 >=20 > These can easily be fixed by changing the test symbol values from > 0x8000000 and 0x9000000 to 0x8000 and 0x9000 so they fit as 16-bit > symbol values. From what I see, the choice of values is arbitrary. Agreed. > FAIL: ld-scripts/empty-address-1 > FAIL: ld-scripts/empty-address-2a > FAIL: ld-scripts/empty-address-2b >=20 > These tests need 0x2000000 changed to 0x2000 and .long changed to > .word as mentioned for other tests, but here there may be a real bug > that needs to be fixed. The tests are checking whether symbols are > defined various ways in a linker script have the correct value. In > the pdp11 target, the symbols are undefined which suggests some > problem with inserting symbols from a linker script into the output > symbol table. I don't know the code well enough to have an idea where > that problem might be. OK, then these should be left as FAIL results for now. > FAIL: ld-scripts/pr18963 >=20 > This one is more complicated. Starting with data.o consisting on only > a header and zero-length text, data and bss the linker script creates > sections that are each 0x10000 long with symbols corresponding to the > section addresses just to test whether addition is commutative using > those symbols. The output generated by that linker script is much > larger than indicated by the a.out header (and several times larger > than the 16-bit address space) making the format invalid, so nm gives > an error. Unless the test could be implemented with sections created > in the object file and just have the symbols defined in the linker > script based on those sections, this test is not supported for > pdp11-aout. This sounds like a reasonable case for an xfail, with a comment along the lines of "this test creates a binary that is too big for 16-bit archite= ctures". > 2) Symbol values with the 0x8000 bit set get sign-extended to 64 bits > in the output of nm, so again they don't match the expected output. > This sign extension is caused by the following statement in > bfd/pdp11.c function NAME (aout, translate_symbol_table): >=20 > in->symbol.value =3D GET_SWORD (abfd, ext->e_value); >=20 > That line is as written when the PDP11 target was added in 2001. > Since addresses are inherently unsigned, why is sign-extension > appropriate? There may be offsets that require the result to wrap > around, but all arithmetic on addresses should be masked to the > number of address bits after the arithmetic operation. I would be inclined to say that this is a bug and change the=20 macro to GET_WORD. There are symbols whose value are not addresses but their signed-ness is not known to the linker, so an unsigned fetch should be safe. > Both of these causes could be avoided simply by reducing the numbers > in the test so that the results are all less than 0x8000, but I belive > the sign extension is a separate bug. I would be happy to review a patch containing the changes you have suggeste= d above... Cheers Nick