[PATCH 3.0/4 v2] MIPS/GAS: Record fake labels like regular ones

Richard Sandiford rdsandiford@googlemail.com
Sat Oct 30 10:18:00 GMT 2010


"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>  The fix below implements it.  I've used the hook called by generic code 
> for each new symbol, but compared to the initial version I have removed 
> the explicit check for fake labels based on your comments addressing the 
> other change.  Like with the original the recording hook is called like it 
> is done for regular labels (except DWARF-2 information is not produced 
> preserving current behaviour).
>
>  Depending on the way symbols are defined this approach causes the 
> recording hook to be called once or twice for the same symbol.  It will be 
> called once for symbols that are not defined as labels, i.e. other than 
> with colon() (which I think still should prevent branch swapping if they 
> refer to code), and for true labels that have been referenced before the 
> actual definition (i.e. forward referenced in the other sense ;) ).  It 
> will be called twice for true labels whose definition is lexically the 
> first ocurrence of the symbol defined.  Due to the complicated matter of 
> dependencies here I have failed to find a way to avoid this double call 
> without turning half of GAS upside down and I didn't feel like defining a 
> new target hook would be the right way to do that either.

Hmm, the target hook sounds good to me TBH.  With your 2.5 patch, we can
now pinpoint exactly when fake labels are created from ".", so a

  tc_instantiate_dot

or suchlike seems like a nice fit.  It avoids having to check the
label value (which looks like a false generalisation) and should
avoid the double calls as well.  (Well, OK, if "." is used twice
in an expression, we'll create two fake labels and get a new call
for each one.  But that's as it should be.)

>  I had to reorder call to clear labels recorded for data directives 
> though.  The problem with them was a newly generated label was recorded 
> in the list as if applying to code that follows.  That would in turn move 
> the label incorrectly if alignment operation was involved.  It could be 
> triggered by code like this:
>
> 	.word	.
> 	.word	.
>
> and possibly for symbols created with .eqv (I haven't checked the latter).  
> The new arrangement is consistent with that used by append_insn() which 
> only calls mips_clear_insn_labels() once all instruction processing has 
> been made that further assures me it's the right change.

This part looks OK to me.  AIUI, the current code doesn't care whether
the mips_clear_insn_labels call is in the old or new position.

Richard



More information about the Binutils mailing list