This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM mapping symbols


Hi Bruno,


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

Well it is a judgement call really.  Providing that the patch does not
get too big then it can be considered to be "obvious" and so not need
a copyright assignment.  I do like to encourage people to obtain
copyright assignments however as we always hope that they contribute
further patches in the future.

> If it is, please give me some more info on this copyright assignment.  

If you are interested, please fill out and send off the attached form
to start the ball rolling.


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

Actually not quite true.  It is the assembly code writer's
responsibility to insert .ltorg directives into their code at suitable
points so that the pools can be generated.  The code in arm_cleanup()
is that to catch the case where a programmer forgets to insert these
directives.  It makes sure that any left over pools are dumped before
the assembler starts to resolve references to their contents.


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

Ok - but this is easily fixed by calling arm_elf_change_section()
after calling subseg_set() in arm_cleanup().  Then the correct-for-
that-section mapping symbol will be emitted, which can then be changed
by your patch to s_ltorg().

[It occurs to me though that the correct thing to do is to change the
 mapping symbol code so that the current symbol is maintained on a
 *pre-section* basis and not just globally.  Since otherwise section
 changes in the assembler source could introduce spurious mapping
 symbols].

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

Agreed.  At first I thought that subset_set() did this, but upon
checking the code I found out that you were correct.

Still I think a per-section mapping symbol state maintained in the ARM
backend would also work and it would be less intrusive into the
generic GAS code.  (You could define TC_SEGMENT_INFO_TYPE and hang the
information off there).

Cheers
        Nick

Attachment: future
Description: Request for FSF copyright assignment


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]