All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] i.MX28: Drop __naked function from spl_mem_init
Date: Tue, 20 Mar 2012 10:09:43 +0100	[thread overview]
Message-ID: <201203201009.43717.marex@denx.de> (raw)
In-Reply-To: <20120320083929.94A98202A50@gemini.denx.de>

Dear Wolfgang Denk,

> Dear Stefano,
> 
> In message <4F683862.4030709@denx.de> you wrote:
> > > +	/* The following is "subs pc, r14, #4", used as return from DABT. */
> > > +	const uint32_t data_abort_memdetect_handler = 0xe25ef004;
> 
> ...
> 
> > Are we maybe becoming warning addicted ? I know the reason for this (GCC
> > raises a warning "-fstack-usage not supported for this target"), you
> > have already asked the gcc people about this issue, and I do not have an
> > idea how to fix this warning in a different way as you did. This is a
> > sort of self-modifying code.
> 
> In which way is this self-modifying code? I don't think so.

Because it rewrites piece of RAM, which is then called in the Data abort 
context.
> 
> > However, the original code is quite easy to understand - I cannot say
> > the same after the patch, we rely on the comment to understand something.
> 
> That's what comments are made for :-)
> 
> > Should we really fix such as warnings even if we generate some obscured
> > code ? Wolfgang, what do you think about ?
> 
> Yes, we should fix warnings.  If you run a MAKEALL and can be sure
> that any message printed is a new problem you will not miss it, and
> act as needed.  If youy know that a build will pop up a number or
> warnings, it's all too easy to miss if there is a new one - and
> checking takes much more concentration.  This is to be avoided.
> 
> On the other hand, I agree that we should avoid obscure code as
> well.  But then, to me the assembler code "subs pc, r14, #4" is
> already obscure enough - I have to admit that I don't really grok it,
> nor why this needs to be a __naked function.

What it does: return from abort mode back from where it was aborted, one 
instruction further.
Why is it naked: Because you don't want to generate prelude etc. only the real 
contents of the function. That gives exactly 4 bytes. And that's what is used to 
rewrite the DABT handler.
> 
> My understanding is that to avoid the warning we can either use this
> "pre-compiled constant instruction" trick, or we would have to create
> a new assembler source file for this single instruction function.

Or put it into start.S

> 
> When Marek and I discussed this, the constant seemed to be the
> simplest approach (not the nicest, though).

Ack
> 
> If you don't like it, then we I think we will end up with a new tiny
> assembler source file.  Would that be preferred by you?
> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

  reply	other threads:[~2012-03-20  9:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Message-Id: <1331903075-10468-1-git-send-email-marex@denx.de>
2012-03-16 21:32 ` [U-Boot] [PATCH V2] i.MX28: Drop __naked function from spl_mem_init Marek Vasut
2012-03-20  7:57   ` Stefano Babic
2012-03-20  8:21     ` Marek Vasut
2012-03-20  8:39     ` Wolfgang Denk
2012-03-20  9:09       ` Marek Vasut [this message]
2012-03-20  9:21         ` Stefano Babic
2012-03-20 17:38         ` Wolfgang Denk
2012-03-20  9:17       ` Stefano Babic
2012-03-20 10:43   ` Stefano Babic

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=201203201009.43717.marex@denx.de \
    --to=marex@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.