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

locating functions automatically

I need to locate a large number of functions in the a specific memory range. I have tried using the ?pr?*?myobject wildcard like this:

?PR?*?myobject (0XC11200)


(myobject has 3 functions: fxn1,fxn2,fxn3)

all it does is locate the first function and then gives these error messages:

*** ERROR L120: CONTENT BELONGS TO ERRONEOUS SEGMENT
    SEGMENT: ?PR?fxn2?myobject
*** ERROR L120: CONTENT BELONGS TO ERRONEOUS SEGMENT
    SEGMENT: ?PR?fxn3?myobject

===
is there a better way to do this? can i simply specify a new memory class and assign my new functions to the new class? if so, how do i do this?

Parents Reply Children
  • Thank you Alex. :) it worked and i was able to locate all my functions in the new class.

    I have a new problem now.

    I am writing a code patch for code that is already deployed. This means that my new generated object has to be linked with the addresses in the existing code.

    Unfortunately, even if i located all my new functions and variables in unused space, the compiler/linker still doesn't generate the same addresses for the old functions.

    Comparing the map files, it turns out that the difference started in the size of the
    ?C?LIB_CODEsegment.

    here's a sample from the map files:

    original:

    800100H   8001FFH   000100H   BYTE   AT..     ECODE          ?PR?C_SYSCALL?SYSCALL
    800200H   80023FH   000040H   ---    OFFS..   CODE           ?CO?ACMB4?1
    800240H   8003B8H   000179H   BYTE   UNIT     CODE           ?C?LIB_CODE  
    8003B9H   800479H   0000C1H   BYTE   UNIT     CODE           ?C_C51STARTUP_MAIN
    80047AH   8004D5H   00005CH   BYTE   UNIT     CODE           ?C_INITSEG
    
    

    patched:

    800100H   8001FFH   000100H   BYTE   AT..     ECODE          ?PR?C_SYSCALL?SYSCALL
    800200H   80023FH   000040H   ---    OFFS..   CODE           ?CO?ACMB4?1
    800240H   8003CFH   000190H   BYTE   UNIT     CODE           ?C?LIB_CODE 
    8003D0H   800490H   0000C1H   BYTE   UNIT     CODE           ?C_C51STARTUP_MAIN
    800491H   8004ECH   00005CH   BYTE   UNIT     CODE           ?C_INITSEG
    

    Because of this, all other addresses sort of "shifted" down the map.

    Is there a way that i can somehow "lock" the original addresses and have the linker simply add/link my new patch code to the original program?

  • I am writing a code patch for code that is already deployed
    if you can get a code patch in, you can get new code in as well. WHY PATCH?

    Erik

  • "if you can get a code patch in, you can get new code in as well. WHY PATCH?"

    Well, the original code is in ROM and it's around 80kb. and i only have around 16kb EEPROM for the patch.
    I still need the patch to be able to call into the original ROM code. Unfortunately, the linker isn't cooperating...

    Any help would be much appreciated.

  • Well, the original code is in ROM and it's around 80kb. and i only have around 16kb EEPROM for the patch.

    And how were you planning on getting that patch code to be called by the ROM image in the first place?

    Unfortunately, the linker isn't cooperating...

    Well, you didn't exactly ask it to cooperate, did you? So far, you're fighting it. You should be linking the original ROM application into your patch project so all functions already present will be taken from that. The "symbols only" option should help with that.

  • "And how were you planning on getting that patch code to be called by the ROM image in the first place?"

    the rom application was written with a patch in mind. it checks certain addresses in the eeprom to see if there is a patch. if so, it jumps to a predetermined address in eeprom.
    This already works and i successfully call into my patch. my problem is the link back. it seems that the compiler/linker determined that i need additional functions in my ?C?LIB_CODE. that's why it grew in size.
    Now because of this, my patch code is linked to a differently mapped version of the rom code, not identical to the original.

    i'm at home now. will look into the "symbols only" option when i get in tomorrow. Thanks for all the help.

  • Michael, I am very interested in finding out if you could make it work and how you were able to compile/link new version of patch keeping ROM binary exactly the same. I am guessing you would need to pin-down some patchRAM code/data (directly referenced by the ROM) to original addresses used during ROM tapeout.

    I have a very similar requirement for my project.

  • actually, i wasn't able to make the full patch work. i did a simple workaround by isolating what parts of the patch caused the CLIB to enlarge and excluded them from the build. then i worked with what i had left...

    I was pressed for time so that was the best solution.
    if you find a better way to do it, please tell me. thanks. :)