lkml.org 
[lkml]   [2013]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ARM: move body of head-common.S back to text section
[Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 18:20) Russell King - ARM Linux wrote:

> On Wed, Jul 03, 2013 at 11:30:12AM -0400, Paul Gortmaker wrote:
> > [Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 11:00) Russell King - ARM Linux wrote:
> >
> > > On Wed, Jul 03, 2013 at 01:19:07AM -0400, Paul Gortmaker wrote:
> > > > As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
> > > > closure are nasty traps waiting to happen and it might be worthwhile to
> > > > audit and explicitly __FINIT them before someone appends to the file...
> > >
> > > That hides a different kind of bug though - I hate __FINIT for exactly
> > > that reason. Consider this:
> >
> > Agreed - perhaps masking that it is a ".previous" just hides the fact
> > that it is more like a pop operation vs. an on/off operation, or per
> > function as we have in C.
>
> I read the info pages, because I thought it was a pop operation too.
> I was concerned that .section didn't push the previous section onto the
> stack.
>
> However, .popsection is the pseudio-op which pops. .previous just toggles
> the current section with the section immediately before it.
>
> So:
>
> .text
> .data
> .previous
> /* this is .text */
> .previous
> /* this is .data */
> .previous
> /* this is .text */
> .previous
> /* this is .data */

Cool -- I bet we weren't the only ones thinking it was a pop. Thanks.

Does that make __FINIT less evil than we previously assumed? I think
your example was the following pseudo-patch:


.text
<some text>
+ .data
+ <some data>
__INIT
<big hunk of init>
__FINIT
/* this below used to be text */
<more stuff that was originally meant for text>

Even if it is a toggle (vs. pop), the end text will now become data,
so the no-op __FINIT with an explicit section called out just below
it may still be the most unambiguous way to indicate what is going on.

>
> > That seems reasonable to me. I can't think of any self auditing that is
> > reasonably simple to implement. One downside of __FINIT as a no-op vs.
> > what it is today, is that a dangling __FINIT in a file with no other
> > previous sections will emit a warning. But that is a small low value
> > corner case I think.
>
> That warning from __FINIT will only happen if there has been no section
> or .text or .data statement in the file at all. As soon as you have any
> statement setting any kind of section, .previous doesn't warn.
>
> So:
>
> .text
> ...
> __FINIT
>
> produces no warning.o

Yep -- we are both saying the same thing here - hence why I called it a
small low value corner case.


\
 
 \ /
  Last update: 2013-07-04 02:41    [W:0.067 / U:23.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site