How to recognize functions start address and end address in binary of PowerPC? - disassembly

Question

Given a PowerPC binary file(ELF), we can disassembly it, but how to recoginze the functions as the IDA pro does? Is there an algorithm?

Answer 1

Can't you use objdump? If the elf file contains the debug symbols, you can see the functions and the code, as for example:
#include <altivec.h>
include
void print_vec_char(char *s, vector signed char _data){
int i;
printf("%s\t:", s);
for (i = 0 ; i <= 15; i++)
printf("%3d ", vec_extract(_data, i));
printf("\n");
}
void print_vec_long(char *s, vector signed long int _data){
int i;
printf("%s\t:", s);
for (i = 0 ; i <= 1; i++)
printf("%ld ", vec_extract(_data, i));
printf("\n");
}
int main(){
vector signed long int output;
signed char x, y;
vector signed char _data;
const vector signed char bits = {120, 112, 104, 96, 88, 80, 72, 64, 56, 48, 40, 32, 24, 16, 8, 0};
// Initialize the vector _data with the same values
_data = vec_splat_s8(-1);
print_vec_char("_data", _data);
print_vec_char("bits", bits);
output = vec_vbpermq(_data, bits);
print_vec_long("output", output);
y = vec_extract(output, 0);
x = vec_extract(output, 1);
printf("First Half = %x\n", y);
printf("Second Half = %x\n", x);
}
and the functions in the elf could be showed as:
# objdump -D test | grep print_vec_long -A 10
0000000000000924 <print_vec_long>:
924: 02 00 4c 3c addis r2,r12,2
928: dc 75 42 38 addi r2,r2,30172
92c: a6 02 08 7c mflr r0
930: 10 00 01 f8 std r0,16(r1)
934: f8 ff e1 fb std r31,-8(r1)
938: 61 ff 21 f8 stdu r1,-160(r1)
93c: 78 0b 3f 7c mr r31,r1
940: 78 00 7f f8 std r3,120(r31)
944: 56 12 02 f0 xxswapd vs0,vs34
948: d0 ff 20 39 li r9,-48
or
objdump -D test | grep print_vec_long -A 10
0000000000000924 <print_vec_long>:
924: 02 00 4c 3c addis r2,r12,2
928: dc 75 42 38 addi r2,r2,30172
92c: a6 02 08 7c mflr r0
930: 10 00 01 f8 std r0,16(r1)
934: f8 ff e1 fb std r31,-8(r1)
938: 61 ff 21 f8 stdu r1,-160(r1)
93c: 78 0b 3f 7c mr r31,r1
940: 78 00 7f f8 std r3,120(r31)
944: 56 12 02 f0 xxswapd vs0,vs34
948: d0 ff 20 39 li r9,-48
Is it what you are looking for?

Answer 2

Look for padding to alignment boundaries as candidates for the gaps between functions.
mflr (move from link register) is often found near the start of a function, if it's used at all. (non-leaf function).
Compiler generate code often ends functions with a lot of reloading call-preserved registers from stack memory, and often has most of the saving early in a function.
Of course, the actual return points in a function might not be the last basic blocks; it's often useful to put the code for a rare condition in a block at the very end past the normal return that's branched to, and then jumps back after doing something.
A real example of compiler-generated code may be illustrative. Compiled by gcc4.8.5 on the Godbolt compiler explorer for PowerPC (32-bit) with -O3 -mregnames
int ext();
int foo() { ext(); return 1; }
foo:
mflr %r0 # save link-register value
stwu %r1,-16(%r1)
stw %r0,20(%r1) # ... to memory
bl ext
lwz %r0,20(%r1) # then restore it after a function call
li %r3,1 # return 1
addi %r1,%r1,16 # stack pointer adjustment
mtlr %r0
blr # ret
Notice that blr (branch to link-register) is used as a return instruction, like x86 ret, instead of simply doing a normal register-indirect jump to the return address in %r0. (Presumably PowerPC handles blr specially, maybe with a return address predictor stack). If the code you're analyzing uses does this, it makes finding the ends of functions much easier. (But remember that tail-duplication optimizations can give a function multiple return paths, and blr won't always be the last instruction.)
The bl target addresses will give you (most of) the function entry points. Have your disassembler put labels on all the bl targets: branch-and-link is basically a call instruction, so the target address is always a function.
Functions that end with a tail-call to another function won't use blr at the end.
If a function is only ever tail-called, there won't be any bl instructions that target it. Or if it's only used with function pointers.
Regular branch/jump instructions that jump more than a few kiB are almost certainly jumping outside the current function to tail-call another function. So you should look at jumps like that as likely candidates for function entry/exit points.