svn commit: r303209 - head/sys/powerpc/booke

[Justin Hibbits]

On Jul 22, 2016, at 10:28 PM, Bruce Evans wrote:

> On Sat, 23 Jul 2016, Justin Hibbits wrote:
>
>> Log:
>> Use label math instead of hard-coding offsets for return addresses.
>>
>> Though the chances of the code in these sections changing are low,  
>> future-proof
>> the sections and use label math.
>
> Not with numeric labels.

I'm not future proofing it against label changes, I'm future proofing  
it against instruction additions/subtractions.

>
>> Renumber the surrounding areas to avoid duplicate label numbers.
>
> New numeric labels tend to move the addresses of old labels.   
> Renumbering
> to give unique numeric labels more than defeats their reason for  
> existence --
> you have to manage them on every change to a label anywhere in the  
> file
> (and perhaps in macros and included files).  You never get a error for
> a duplicated numeric label.  Non-unique numeric labels are also a good
> obfuscation.  Given a branch to 1f or 1b, grepping the file for 1: may
> find many labels 1:.  You have to examine all the labels named 1: or
> search only near the jump to see where 1 is.  Its name is supposed to
> not matter, but perhaps it does.

I debated renumbering, and in my first iteration I didn't, but decided  
to for final commit, just for pure aesthetic purposes.  In the future,  
I expect a lot of 0: labels for number labels, but as you mention  
below, named labels should be used for most labels anyway.

>
> Numeric labels should only be used in macros, and then only when the
> macro processor is too feeble to support generating unique non-numeric
> labels.  Standard cpp is too feeble for this.
>
> I managed to remove all numeric labels in i386/exception.s (except in
> macros and included files), and none came back.  amd64/exception.S has
> 19 of them, 7 with the additional style bug of being on a line with
> a statement or comment.
>
> Bruce

- Justin