Re: inline asm string/line break rules change

[Joel Sherrill <joel at OARcorp dot com>]

Franz Sirl wrote:
> 
> On Saturday 13 April 2002 21:31, Andi Kleen wrote:
> > Joel Sherrill <joel@OARcorp.com> writes:
> > > If there was a discussion on this, I must not have missed
> > > it or not realized the potential impact.  I sure don't want
> > > to begin to modify other code bases until I know the intention.
> >
> > It's also a big problem for the linux kernel and for various other
> > packages.
> 
> kernel is fixed for a long time and there are only a few packages out there
> using inline assembly heavily.
> 
> >  Even if there should be good reasons to discourage multi line string
> > I think it shouldn't be warned until an alternative inline assembly
> > syntax that doesn't rely on strings exists. Currently it is discouraging
> > one practice with no good replacement.
> 
> Please? A warning is there since gcc-3.0! 

But for all practical purposes, gcc 3.0.x was unuseable for embedded
targets.
Many of the targets that worked with 2.95.x were broken in the 3.0
transition
so the embedded community tended to ignore 3.0.x.  My efforts have been
focused
on getting problems reported so they can be fixed.  gcc wouldn't even
build 
itself and newlib on many embedded targets for C and C++ much less the
full
language suite. 

Unfortunately, (I suspect) the embedded community is where most of this
type 
of code is going to be found.  A spot check of newlib's CVS shows that
no effort
has been put into this.  I have been emailing with someone fighting the
xscale
specific code and that's all the activity I know of. 

What about *BSD, gdb stubs, libraries with hand optimized insertions 
(e.g. in_cksum routines in TCP/IP stacks or C libraries)?  How many 
pieces of code are impacted?

In fact, a quick check like this:

find . -type f | xargs -e grep "asm volatile" | wc -l

found 4 in gdb 5.0, 18 in newlib 1.10, and 479 in RTEMS.
But search for "asm " and the numbers shoot up to
381 in gdb and 135 in newlib.

Try "asm(" and you get 71 more for newlib and 167 for gdb.

That sums up to over 500 places to check in gdb and 
about 250 in newlib. 

> And adding the 3 chars \n\ to each
> multiline isn't that hard, with Joel's example:
> 
>  asm volatile(" movw %%ds,%0
>                 movw %, %%es"
>                : "=r" (tmp_segment) :
>                : "0" (tmp_segment) );
> 
> would turn into
> 
>  asm volatile(" movw %%ds,%0  \n\
>                 movw %, %%es"
>                : "=r" (tmp_segment) :
>                : "0" (tmp_segment) );
> 
> Seems easy enough to me (did it to the ppc assmbly in glibc for example).

I am not contesting that it is hard -- just that it is a change to
fragile
code.  And that there is a lot more code of this sort around than was
able
to be compiled with gcc 3.0.

No one has answered the question which would convince me this is a 
warranted change.  What is the real technical merit for doing this?
If there is a valid technical reason, then I will suck it up and
start to modify code.  

But I don't see the technical reason yet.
I only see busy work modifying code that is easy to break. :(

> Franz.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985