Re: ARM mapping symbols

[Richard Earnshaw <rearnsha at arm dot com>]

> 
> > 
> > I have some reservations about the patch:
> > 
> >   * Why is the forced argument needed for the mapping_state() function
> >     ?  Surely if the last mapping symbol emitted was a data symbol,
> >     then there is no need to emit a new one ?
> 
> That would be the case if the object was assembled from top to bottom, 
> which is not the case for the literal pools. As the literal pools 
> need to be appended after a function return or an unconditional jump they 
> cannot be assembled until the rest of the code is assembled. Although this 
> could probably be handled differently, at the moment the creation of the 
> table is even deferred until all sections are assembled. 

The concept of forcing a state machine like this seems entirely bogus to 
me.  Why is it not possible to make the state machine track things 
properly?  The only special state in the machine should be 'uninitialized' 
when a new section is started.  After that all transitions should be 
determined by what is being emitted.

Note that it looks to me as though the current implementation doesn't 
support multiple code sections.  Consider this code:

	.text
	.arm
f:
	bx	lr

	.section a, "ax",%progbits
	.thumb
g:
	bx	lr
	.text
	.thumb
	bx	lr


assembling this file shows that there is only one $t mapping symbol.  
There should be two, one for each code section.

R.