public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Gerlando Falauto <gerlando.falauto@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] analyze/change assembly code
Date: Tue, 30 Oct 2012 12:08:01 +0100	[thread overview]
Message-ID: <508FB511.2020403@keymile.com> (raw)

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?

Thank you,
Gerlando

             reply	other threads:[~2012-10-30 11:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30 11:08 Gerlando Falauto [this message]
2012-11-10 11:25 ` [U-Boot] analyze/change assembly code Albert ARIBAUD
2012-11-19  6:23   ` Gerlando Falauto
2012-11-20  8:54 ` Marek Vasut
2012-11-20  9:43   ` Gerlando Falauto
2012-11-20 13:26     ` Marek Vasut
2012-11-20 13:40       ` Albert ARIBAUD
2012-11-20 13:48       ` Gerlando Falauto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=508FB511.2020403@keymile.com \
    --to=gerlando.falauto@keymile.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox