assembler relaxation

Nick Clifton nickc@redhat.com
Thu Dec 31 12:15:00 GMT 2009


Hi Nagaraju,

>> Obviously some other part of the assembler is corrupting the contents 
>> of the opcodep[] array.  If you have access to a debugger (eg gdb) I 
>> would suggest that you run it and place a watchpoint on opcodep[2] and 
>> opcodep[3] to see how they get corrupted.

> (Nagaraju) I have kept the watchpoint at that location but no where it 
> is getting hit.

It would definitely be worth investing some time in order to try to find 
out where/when this corruption occurs.  GDB should be able to point a 
watchpoint on the memory address of opcodep[2] for example, so you 
should be able to track down th culprit.

>> Without knowing more, my guess would be that it is connected with 
>> how/where this opcodep[] array is declared.  Is it part of a bigger 
>> structure that gets reused maybe ?
> (Nagaraju)      opcodep[] is pointing to fragp->fr_opcode.
>      it is declared in md_convert_frag
>    {
>      unsigned char *opcodep;
> 
>     opcodep = fragp->fr_opcode;
>               ....
>    }

Hmm, I think that the problem might be that you are continuing to use 
the frag after having inserted the new instruction.  You may find that 
you need to add a call to frag_new() after you have added the CMP 
instruction.

Cheers
   Nick






More information about the Binutils mailing list