Re: ARM mapping symbols

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

On Mon, 8 Mar 2004, Nick Clifton wrote:

> Hi Bruno,
> 
>   [Please could send patches to the GNU binary utilities, including
>    GAS, to the binutils mailing list: binutils@sources.redhat.com]
>
> > I noticed that you implemented mapping symbols for the
> > ARM-architecture.  However, it seems like the literal pools (the
> > main reason for data in code on the ARM ) do not get a $d
> > symbol. The attached patch solves the problem.
> 
> Thank you very much for submitting this patch.  There is one initial
> problem however: do you have a copyright assignment on file with the
> FSF ?  Without such an assignment we could not accept the patch :-(

Is this really necessary? The patch is very small (I add a parameter to 
the mapping_state function, change all call sites (11 lines) and 
change one check in mapping state to check the extra parameter (1 line)), 
so I believe this would fall under "not legally significant for 
copyright". If it is, please give me some more info on this 
copyright assignment.  

> 
> > It's just a quick hack, I simply force the addition of a $d 
> > symbol before each literal pool. For a clean fix, I would have
> > needed to change some of the core gas files.
> 
> Which files ?  [Clean fixes are always preferred to quick hacks :-)]

See the comments below...

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

(It is called in arm_cleanup:
  void arm_cleanup()
  {
    literal_pool * pool;

    for (pool = list_of_pools; pool; pool = pool->next)
    {
      /* Put it at the end of the relevent section.  */
      subseg_set (pool->section, pool->sub_section);
      s_ltorg (0);
    }
  }
)

Correct me if I'm mistaking, but it appears to me that this is the only 
place in the code where the tables can be emitted (which would mean that 
all literal pools are at the end of a section). This would cause problems 
if the code section became to big to address the literal pool (larger 
than 4K for 32 bit loads, 256 bytes for halfword loads), but as far 
as I can see, literal pools are only used in some assembly files, like 
crt0.S that are small enough... (gcc does not use the literal pool 
implementation in GAS, but inserts its own tables...) 

So, what is the problem:

The last assembled section is often a data section, so the mapping symbol 
is $d. Then arm_cleanup is called and the literal pool(s) is(/are) 
written. As the last symbol already was $d, no new symbol is added... 
the same would happen if you would add literal pools to different 
sections: the first could get a $d symbol, the others would not...



> Which files ?  [Clean fixes are always preferred to quick hacks :-)]

It would also be possible to change subseg_set to find out when we jump 
from one part of the file to another. This would probably be cleaner....


>   * If you are going to emit a data symbol at the start of the literal
>     pool, then you will also need to emit a text symbol at the end of
>     the pool, so that debuggers etc can tell that .text section now
>     contains code and not data.

Yep, if there were literal pools that were not at the end of a section. 


> Cheers
>         Nick
>         
>

Attachment: binutils_mapping.patch
Description: Text document