From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 20 Nov 2012 14:26:15 +0100 Subject: [U-Boot] analyze/change assembly code In-Reply-To: <50AB50B8.3010606@keymile.com> References: <508FB511.2020403@keymile.com> <201211200954.46861.marex@denx.de> <50AB50B8.3010606@keymile.com> Message-ID: <201211201426.15738.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Gerlando Falauto, > On 11/20/2012 09:54 AM, Marek Vasut wrote: > > Dear Gerlando Falauto, > > > >> Hi all, > >> > >> we recently to had face some nasty issues, where for some reason two > >> (functionally identical) versions of some code behave very differently. > >> Namely, one version works and the other doesn't always work. > >> It was clear from the beginning this was because of HW- (or compiler-) > >> related issues. > >> I thought it would then be useful to have a peek at what the compiler is > >> doing behind the scenes, and possibly make some simple changes to the > >> code. For instance, inserting some nops here and there, or reordering > >> some instructions, may help in tracking down these different behaviors. > >> > >> I know the easiest way to LOOK at the file is simply to use objdump to > >> disassemble an .o file. In the end I somehow managed to tamper with the > >> makefiles so to get what I wanted for a given file, by adding a fake new > >> ".s" target with the recipe to build it, and having the .o file depend > >> on a ".S" file (which would be a manual/changed copy of the generated > >> ".s" file) instead of the original ".c" file. > >> This is however not linear and nice at all. So I was wondering whether > >> there already is a well-established way of having the make process > >> create (and keep) assembly files which can be then manually changed. > >> > >> Does my question make any sense at all? Any ideas? > > > > What compiler do you use? The Linaro one didn't behave properly for > > example. > > powerpc-linux-gcc (GCC) 4.6.4 20120303 (prerelease) > arm-linux-gnueabi-gcc (GCC) 4.6.4 20120303 (prerelease) Where did you get this from, ELDK or elsewhere? > What do you mean it didn't behave properly???? How's that even possible? The Linaro toolchain had broken libgcc and u-boot pulls in components from this libgcc ... thus the breakage. > A compiler which doesn't translate to assembly and from assembly to > binary is by definition a _BROKEN_ compiler, so I strongly doubt that... > Or maybe I got you wrong? > > Best regards, > Gerlando Best regards, Marek Vasut