• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 21 subscribers
  • Views 1533 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

L13 Warnings don't make sense

Chris Beattie

I decided to start a new thread since this problem is different than the original one.

When I compile the attached code, I get four L13: Recursive Call to Segment Warnings. One of the functions called out in the warnings is this one:

BYTE process_Help(char xdata *cmdBuf)
{
    printf("\r\nP2_CMDHELP\r\n");
    printf(cmdBuf);
    cmdBuf[0] = '\0';
    printf( "\r\nHelp Message\r\n"
    return TRUE;
}

which is obviously not recursive. If anyone can figure this out, it would be greatly appreciated. You can download the code from:

http://briefcase.yahoo.com/bc/cbeattie/lst?.dir=/Keil&.view=l

You'll need to correct Keil's standard reg530.h file with standard C/C++ include file protection by adding this to reg530.h:

// First two lines of corrected reg530.h
#ifndef _REG530_H
#define _REG530_H
.
.
.
#endif  // Last line of corrected reg530.h

In order for the code to compile.

Thanks,
Chris Beattie

Parents
  • 0 in reply to Jon Young

    I read the app note and thought that the way I was doing things took all of that into account. I moved the declaration of the function pointer table out of the function and into global space in the bootUart.c file (instead of bootCommands.c) and that also got rid of the warnings, so it doesn't have to be declared in the function, just in the file.

    Why would it make any difference which file the table is declared in?

    Thanks,
    Chris

Reply
  • 0 in reply to Jon Young

    I read the app note and thought that the way I was doing things took all of that into account. I moved the declaration of the function pointer table out of the function and into global space in the bootUart.c file (instead of bootCommands.c) and that also got rid of the warnings, so it doesn't have to be declared in the function, just in the file.

    Why would it make any difference which file the table is declared in?

    Thanks,
    Chris

Children
  • 0 in reply to Chris Beattie

    It's a while since I looked at this stuff, and it wasn't quite applicable in my case, but I seem to remember something about it making it easier for the compiler/linker to make correct "guesses" about the pointers?

  • 0 in reply to Andrew Neil

    That's it exactly. But, since this is explained pretty well in the app note, I shall not preach! :-)

    Jon

  • 0 in reply to Chris Beattie

    The Kiel compiler/linker is not stacked based w.r.t. to local variables. The linker makes a call tree for the functions and statically allocate variables, overlapping them whenever possible. So it is imperative that the linker can create this tree error free, else you can get incorrectly overlapped variables. (That error is great fun to debug.) Things work fine until you get to fn ptrs. In your case the fn ptrs values were declare in the "constants" space of one particular file. To get the program to link correctly, you have to remove this association to this "constants" space of the particluar file and remap it to the correct function. I find this a high maintenance way of doing things (and difficult to explain). I perfer to move the fn ptr declarations into the proper function (even if I have to make a helper function). At that point it is a no brainer, which is something I can handle.