It cannot be solved in all cases.
Some string (start) is not referenced in the whole
text at all, even if you turned on all optimizations. Let's see the following example.
#define _FILE strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__
_FILE will point the filename instead of the full path, however, the compiled
elf will contain the whole
__FILE__ string (the whole path) (See more details here.)
In this case,
.rodata will be seen like this:
$ readelf -p 10 a.out
String dump of section '.rodata':
[ 0] Hello world
[ ab12] /your/build/folder/awesome.c
text will not refer the
0xab12 anywhere, because
_FILE points to
0xab25 (the start of the
awesome.c) and the
text will refer to this
A workaround can be that checking all offsets of a given string.
The following solution works with MicroBlaze GCC, but the solution approach is general, so it can be applied to all architecture.
Find a known string in
rodata. (A string with known usage. For example print a Hello world message at the beginning of the main.) Check out the compiled assembly. MicroBlaze GCC uses the strings in
printf as following:
1ec: b0000000 imm 0
1f0: 30a09fc8 addik r5, r0, -24632 // This is the HELLO WORLD
1f4: 31000004 addik r8, r0, 4
1f8: 11330000 addk r9, r19, r0
1fc: b9f45a58 brlid r15, 23128 // 6954 <printf>
So this compiler refers the addresses as 16 bit signed values.
To get the referring code line, convert the
0xfada (the absolute address of the
awesome string) to 16 bit signed integer
-1318 and search (grep) for this value in the disassembled