Re: ARM mapping symbols

[Bruno De Bus <bdebus at elis dot ugent dot be>]

On Mon, 8 Mar 2004, Richard Earnshaw wrote:

> 
> > 
> > > 
> > > 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.

I agree, it was a dirty hack, but it produced "better" results than the 
current implementation. (And if our link-time optimizer can handle 
the binaries, chances are that the information was indeed correct) 
Forcing the state machine is indeed not the correct solution but the 
problem is that the current implementation does not see all state 
changes....

> 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.
>