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]

Re: RFC: Possible tc-mn10300.c patch


Hi Richard,

> I'm coming across a problem in the mn10300 port for GAS. For a
> non-relaxable section like .debug:
> 
> 	.section	.debug
> _f:	.4byte		_f
> 
> GAS doesn't output a reloc.  This seems to happen whenever a non-relaxable
> section contains the address of a symbol in the same section.  Looking at
> md_apply_fix3 in tc-mn10300.c, there's a condition:
> 
>   if (fixp->fx_addsy != NULL
>       && (! S_IS_DEFINED (fixp->fx_addsy)
> 	  || (S_GET_SEGMENT (fixp->fx_addsy) != seg)))
>     {
>       fixp->fx_done = 0;
>       return 0;
>     }
> 
> but, after avoiding that return, fixp->fx_done always gets set to 1 for
> BFD_RELOC_32 and the like.
> 
> I tried changing it so that fixp->fx_done is only set to 1 if there is no
> symbol involved, and that solved the problem I was seeing. But I'm not
> sure if this is generally OK.  Still, I've attached the patch below.  I'd
> appreciate it if anyone can tell me the right way.

I believe that this approach is generally OK, unless the reloc is
pc-relative.  In theory a PC-relative reloc against a strongly defined
symbol in the same section should be resolvable by the assembler and
should not need a reloc being generated.  Of course generating the
reloc would not do any harm, (although it would make the object file
slightly larger) so I think that your approach will be OK.

> 2001-02-21   Richard Sandiford <rsandifo@redhat.com>
> 
> 	* config/tc-mn10300.c (md_apply_fix3): Don't mark a fixup as
> 	done if it's against a symbol.

Approved.

Cheers
        Nick


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