• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 21 subscribers
  • Views 1662 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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

Indirect branch and function attributes

Lorenzo Niceforo

Hi to everyone,

i am trying to use pointer functions to do indirect branch in C code, i am working with an NXP ARM LPC2478

This is my code:


// in internal flash
unsigned char* MD5BuffSE(unsigned char *pBuffer, unsigned long lOffset, unsigned long lSize)
{
   ...
}

g_CriptAddress.pMd5 = (void*)&MD5BuffSE; // g_CriptAddress is an array of void*


.....

// in internal ram @ 0x4000fd00
typedef unsigned char* (*MD5)(unsigned char* , unsigned long , unsigned long );
MD5 Md5 = (MD5)g_CriptAddress.pMd5;

if(memcmp(Md5((byte*)TOS_START, 0, TOS_DIM),pDataProt->ChkSumMd5,16)!=0)
        return false;

with this code all seems to works fine (code jumps to the right address and returns well), but next branch causes execution to fail with an abort exception.

if i use MD5BuffSE directly all works, but i noticed that compiler insert a long ARM to ARM veneer

so i ask myself if exist a way to tell compiler that it has to consider typedef MD5 a far call or to force it to create a long ARM to AMR veneer

what happens when i call a thumb function from arm code with indirect branch?

Lorenzo

Parents
  • 0 in reply to HansBernhard Broeker

    if i have well understood, you are saying that i have to do something like this:

    
// in internal flash
unsigned char* MD5BuffSE(unsigned char *pBuffer, unsigned long lOffset, unsigned long lSize)
{
   ...
}

typedef unsigned char* (*MD5)(unsigned char* , unsigned long , unsigned long );

g_CriptAddress.pMd5 = &MD5BuffSE; // g_CriptAddress.pMd5 is an MD5 type


.....

// in internal ram @ 0x4000fd00
MD5 Md5 = g_CriptAddress.pMd5;

if(memcmp(Md5((byte*)TOS_START, 0, TOS_DIM),pDataProt->ChkSumMd5,16)!=0)
        return false;

    it seems to do the same thing, compiler do not add a long ARM to ARM Veneer

    is this what you call "function pointer type"?

Reply
  • 0 in reply to HansBernhard Broeker

    if i have well understood, you are saying that i have to do something like this:

    
// in internal flash
unsigned char* MD5BuffSE(unsigned char *pBuffer, unsigned long lOffset, unsigned long lSize)
{
   ...
}

typedef unsigned char* (*MD5)(unsigned char* , unsigned long , unsigned long );

g_CriptAddress.pMd5 = &MD5BuffSE; // g_CriptAddress.pMd5 is an MD5 type


.....

// in internal ram @ 0x4000fd00
MD5 Md5 = g_CriptAddress.pMd5;

if(memcmp(Md5((byte*)TOS_START, 0, TOS_DIM),pDataProt->ChkSumMd5,16)!=0)
        return false;

    it seems to do the same thing, compiler do not add a long ARM to ARM Veneer

    is this what you call "function pointer type"?

Children
  • 0 in reply to Lorenzo Niceforo

    it seems to do the same thing, compiler do not add a long ARM to ARM Veneer

    That's insufficient evidence to support that conclusion. The difference this make could just as well manifest itself at this point of the code, instead:

    g_CriptAddress.pMd5 = &MD5BuffSE; // g_CriptAddress.pMd5 is an MD5 type

    One possible problem that can be caused by mixing function pointers with data pointers is that the compiler might be using shorter pointers for data than for code, which would cause a (void*) cast to lose significant bits. This would more likely cause a code difference in the above line than in the place where a call is made via mMD5.

    To really check whether the change of type for pMD5 makes a difference, you should compare program hex files before and after the change.