Hi, >> Now, I know what is going on, but I do not know why: the >> __builtin_return_address() corresponds to a value in the text segment, >> which has fde entry, but: >> - __builtin_return_address() returns back the run-time address of the >> text segment >> - the fde entries contain the link-time address of the same text segment. > > I'm not sure I fully understand this. Are you saying that the runtime > and link time addresses are different? How is the runtime address > determined? It is done using a linker script, or are the instructions > moved around dynamically at runtime? I speak strictly from run-time: when the gcc tries to find the fde for a text segment, the __builtin_return_address() corresponds to the run-time (memory) address of a text segment, but the fdes contain the link-time addresses of the text segments in run-time. In other words when the binary_search_unencoded_fdes() function is called, its pc parameter is a desired run-time memory address of a text segment in the memory (0x2344eca7), but the ob->u.sort->array[i]->pc_begin items are link-time addresses between the range 0x400000-0x500000. Obviously, comparing link-time addresses with run-time addresses will never match. The relationship between address in the memory and during link-time: link-time address = (run-time) address in the memory - gp register value + _gp. Ok, so now the question is: why the fdes do not contain run-time addresses of the text segments in run-time? A solution can be to convert the link-time addresses of the fdes into run-time, memory addresses on-fly, but I should extract/know somehow the _gp symbol address and the gp register (r28) to use the previously mentioned equation in reverse way to get the memory addresses of the text segments stored in the fdes. I hope now it is more clear. I have not hacked gcc before and mipsel is my first platform to do it. :) Csaba
