m68k padding between methods at ld time

[Joel Sherrill]

Goswin von Brederlow wrote:
> Joel Sherrill <joel.sherrill@oarcorp.com> writes:
>
>   
>> Hi,
>>
>> I have been looking at an objdump of a Coldfire application
>> and noticed that the fill pattern between methods is
>> 0x4e75 which is an rts not 0x4e71 which is a nop.
>>
>> Is this because ld/emulparams/m68kelf.sh has this:
>>
>> NOP=0x4e754e75
>>
>> This is with pre-release snapshots and the CVS head
>> for the source check.
>>
>> Thanks.
>>
>> --joel
>>     
>
> What is the problem with that? If someone jumps between functions it
> would return instead of running into the following function. Seems
> more sane.
>
>   
Actually it makes more sense to have an unimplemented
instruction so you have a high probability of getting a fault.
Whether the CPU does an rts or fails into the next routine,
it is in error.  An unimplemented instruction would help
diagnose it.

But that is a change in philosophy which impacts all targets.
Right now, ld pads with nops.  To change this, you would have
to (1) make a case for doing so and (2) provide unimplemented
instructions for all ports.

FWIW I have been analysing objdumps on SPARC, x86, ARM
and Coldfire as part of object coverage analysis of RTEMS.
Putting anything other than a nop or unimplemented instruction
is confusing.  Our helper tool tries to deduce instructions between
methods are not to be executed and for simplicity assumes nops
are executed.  We should be able to assume that an instruction
with a side-effect appears in the executable because you might
want to execute it.
> MfG
>         Goswin
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985