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