This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

function pointers in Dallas 390 contiguous mode

I was struggling with the function pointer in Dallas 390 contiguous mode. It seems that the linker might not relocate the correct address in function pointer. Check the following code:


void Test(void)
{
    UINT32 u32Tmp;

    u32Tmp = 0x12345678ul;
    TASK_PRN(("u32Func = %lx\n", u32Tmp));
    u32Tmp = Test;
    TASK_PRN(("u32Func = %lx\n", u32Tmp));
}

The Linker generate the address for Test: Test function is located at 2D90EH. 02D90EH 02D957H 00004AH BYTE INSEG ECODE ?PR?TEST?TASK The TASK_PRN macro calls my own written printf utility. Here is the output: u32Func = 12345678 u32Func = 83d90e I couldn't figure out why is this happening. Keil C version : C Compiler : C51.Exe V7.20 Assembler: AX51.Exe V2.13 Linker/Locator: LX51.Exe V3.64 Librian: LIBX51.Exe V4.24 C compiler Setting: LARGE OMF2 ROM(D16M) OPTIMIZE (SIZE) BROWSE ORDER MODDP2 Any body encounter this problem ? Thanks in advance! Lucas

Parents
  • The bug is in your expectations, not in the linker. What on earth made you assume you knew what the result of casting a pointer to an integer was, better than the tools that actually use those pointers? Do you know what terms like "undefined behaviour" or "unspecified result" mean?

    Not only is your expectation unfounded, it actually contradicts the documented behaviour, too.

Reply
  • The bug is in your expectations, not in the linker. What on earth made you assume you knew what the result of casting a pointer to an integer was, better than the tools that actually use those pointers? Do you know what terms like "undefined behaviour" or "unspecified result" mean?

    Not only is your expectation unfounded, it actually contradicts the documented behaviour, too.

Children
No data