0

I'm playing with coldfire disassembler and find out this piece of code:

loc_F7E:
    bsr.l loc_F7E+2
    lea 12(sp),sp
    pea (284).w
    clr.l -(sp)
    move.l  a6,d0
    addi.l  #-636,d0
    move.l  d0,-(sp)

loc_F98:
    bsr.l loc_F98+2
    lea $C(sp),sp
    pea (284).w
    clr.l -(sp)
    move.l  a6,d0
    addi.l  #-$398,d0
    move.l  d0,-(sp)

I'm trying to figure out what is the need for those bsr.l. For me it is only jumping itself.

Paul R
  • 208,748
  • 37
  • 389
  • 560
Michel Boaventura
  • 23
  • 4
  • Is there anything else after the `move.l d0,-(sp)` in each case ? – Paul R Nov 12 '14 at 22:25
  • No, just that. It is strange because it pushes some values on the stack as is if it was going to call a subroutine, but just calls itself. – Michel Boaventura Nov 13 '14 at 00:38
  • 3
    Is this an executable, library, object file, or what ? I just wonder whether the bsr destination address is actually just a placeholder that gets fixed up at link/load time ? – Paul R Nov 13 '14 at 06:40
  • It is an elf file and this particular code is a peace of a exported function. – Michel Boaventura Nov 14 '14 at 12:16

2 Answers2

1

According to manual, bsr.l *+2 has hex code $61FF $0000 $0000, so it is most probably result of disasming an object code with unresolved relocations, as Igor Skochinsky has mentioned above.

lvd
  • 793
  • 3
  • 12
0

I think these might be the result of a compiler optimization for more compact code. See "Short BRA Optimization" in the compiler guide.

Recent IDA versions disassemble such branches as skip2 (there is also skip1) for HC08 and HC12 code. I haven't seen such optimization in ColdFire code before.

EDIT: or it could be just an object file with unresolved relocations.

Igor Skochinsky
  • 24,629
  • 2
  • 72
  • 109