From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by server2.sourceware.org (Postfix) with ESMTPS id 230663943544 for ; Sat, 7 Mar 2020 21:05:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583615124; bh=ahVPxUKrI0mXxBReRHUtsFlDXoecYD9gW9dvCKU8mK0=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=Fha7OnJRcDuzli0DIf9ibMGKnblvX3TNmMJ3BDybOoevC2DI8RnkHqxL9mx+HciqH rV6Qm5VIzuZQN3CbxRreV8aceLL1TDulbvytnAolft7W86NSmragW335DloTGpwsMZ lXf7elBmynKIfv0kAnifCTwhqcLqQ1Rbyakm5WfY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from zbook-opensuse.wgnetz.xx ([95.114.38.227]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MxlzI-1jYY0Y06iU-00zDxf; Sat, 07 Mar 2020 22:05:24 +0100 From: Christian Eggers To: Alan Modra Cc: binutils@sourceware.org, nickc@redhat.com Subject: Re: [PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers Date: Sat, 07 Mar 2020 22:05:23 +0100 Message-ID: <2565487.qrDekGRkqd@zbook-opensuse.wgnetz.xx> In-Reply-To: <20200227083541.GI32593@bubble.grove.modra.org> References: <20564877.7Tol0G4XMo@zbook-opensuse.wgnetz.xx> <13081552.YODp3BJPb1@zbook-opensuse.wgnetz.xx> <20200227083541.GI32593@bubble.grove.modra.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K1:wM5fcp6tMWBj0YA3ugou5uxJey4dG1qrH3uEKA5xb/562ZapQJt em4IISrUk4W+Y04cSjcLMlHm2nAM7SkNOuTzr/n+Lw7rb5/mIfgnxm74VaWi4VTK3rhT/ls 46EQqQxoid5i1Hsfd2oQw0VIFKqpKTAnPvtbtqfE9ufq1jjwl1mE7e5gmuAvgBMNOmjN0jq IddR9ITEwqMh75uLKHMOQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:b79EcqfV2y0=:y0SN3ojfKoI4vD+zChtfce xpptg40787TqrIoyVbDScM6HCD9THArPbZdxIRuFYjp1xizvpA0ohKl5e6f3Vts9+RhNP9mlt imFZpSiEglkuptRgcojSwxrvGvMwhmSWHofcepUhyYUJ2mXjyuOK3W/SQ1Qwkq7vru8dRrIIY qXr4rvrnUmcpaDXk5wBZ+VBtL72bGvNaf7aUEbe5CckpJzSPCOEzEejvzlViAtNRC04/QqEk6 ScO279THYviZHJsZkA1LsaIXbtLFs1OJueE8Q662/PkfFD0VSnZSkMuIFgSI0iCf5t7Bs+jF3 kTP0fz8Bdukbaih9Ctcktqk4d9MkqqtKyw5q7rxzkW0VHSJYDH3tus3Wdrt0lQkTqyNe/r8Df Kac1oPY04+O1PMOEs5G54TR2dlSCK66vYXBQVkY9q0Dj78Rh+UQHFyKJdM/3FVaxsa1w+QQJP +RPR/JTYeHzq8sfDe4SvIJqDRzIm95CfAadvt/mmyaiL7i77u/xNPmRtIQ28Pi7RK4Ev0syOH Dl6bhLTfjdNohHinK/GObYKkmZwwAdQC4E/7TMxHYKyI69sxMz5g9e1T3KniwN5XxqtZqv0Y2 ARVfN7hBQaAbkU87F+WLlhCmB159gfawkEYddKrlOYpUo6TrbKofeLYLH2QSlZ454XbdF4/gw xe+RuZlZR1PW8QrtfzKd4/eM7lLCvUOXlkBnGHyzWCNyXMDGJrJ08kkKuSSH3YdPvxk/9oRim ScHjYxrx0y6zCUH8CVNwx/xO7wWPHx0W1iSMGsFqKuaSEJEtQrcBylfwiosFS2ysMnMqccQjF 9+mRecvbUF3925F8PUhz0vLBQWgB9eMpYm+gwI+HN9X7uxlLC/9K1RFpTTpw/AdB7BCyNiU1H l5fooy77gfM6V5Kb+dO+g8ysFmDul/S0Rk6wrISW0nwrZETMP6jome+5FUce2Jh6r6yRKiXDl aJz1UNeHp8Fp9eOZtn3NUdzbqquXrKZHWEqjv43fn2nPATXN2lyjoVGQvGIK7AAhxH9K6PJT/ EGzyYs4usHwYaHcUFmwglJl2iU1r0FG386CfmGh4QgPjiib7mqOOiNvHq5aVzgaGM7pjLXTB/ DsfEroGmdlDS1ii4HMk6fH1COxyj/XiBg2P+NHEKqAnR5xtC6WfWRj7coP8WGllIpgojJlnEQ HMg3Rt0fVeMjYJfp2xvFAT0tflChfRHY/EQIgRjKtzYxz7VU2pyi9e0rQr0KHruJEFmuYmaio 2v71eJ2dtyehlrtBC X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_40, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS 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: Sat, 07 Mar 2020 21:05:32 -0000 Am Donnerstag, 27. Februar 2020, 09:35:41 CET schrieb Alan Modra: > Symbols are a real problem, not because of some implementation detail, > but because you don't know the units of st_value. A symbol defined as > a label on a line of assembly holds an address, but for example a > symbol defined by > sym =3D 123 > could be a size in octets, an address, or just a plain number. Maybe this is not the main problem (at least for SDMA). All "plain" number= s in assembler are most likely bytes. If somebody requires octets in future, a = new ".octet " directive might help... > I think that if you decide that symbol values should always be octets, > then you'll eventually come to the conclusion that addresses in the > assembler need to be octets too. I've made a short try to store st_value and .debug_line statements in octe= ts. For this experiment I simply multiplied st_value by 2 in the swap_in and swap_out functions. While this worked quite well (as all "octet" symbols h= ad a value of 0), making this change for debug information ended in finally giv= ing up. It started harmless with expressions which became fixes. But then some= of them became relocations where it is difficult/impossible to know which one= s have to be shifted and which ones not... > And then it's just easier to dispense with octets_per_byte. Tried to translate the outcome from German into English: Hindsight is easi= er than foresight. When I started with SDMA, I already had a presentiment that support for octets_per_byte might be incomplete for ELF/DWARF. But I liked the possibi= lity of having correct addresses in assembler code and in objdump output and I didn't want to use the obsolete coff/stabs format. I suspect that using octets_per_byte=3D1 for SDMA would complicate things = for the user and additionally would set back my SDMA port by several months (m= aybe that I will be unable to complete it in this case). > So if you're going to keep octets per byte of 2, I wouldn't be trying > to convert any symbol values. As I don't want to add further complexity to this, I would like to keep st_value, r_addend and r_offset like it is for now. If you are ok with my latest patches, I would like send the first version = of the SDMA port. After working countless weekends on my first binutils port, it's time to finish... Regards Christian