From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sat, 10 Nov 2012 12:25:22 +0100 Subject: [U-Boot] analyze/change assembly code In-Reply-To: <508FB511.2020403@keymile.com> References: <508FB511.2020403@keymile.com> Message-ID: <20121110122522.0ec88a39@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Gerlando, On Tue, 30 Oct 2012 12:08:01 +0100, Gerlando Falauto wrote: > 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? Add -save-temps to the gcc arguments? Watch out for parallel build issues, though. Amicalement, -- Albert.