• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 1282 views
  • Users 0 members are here
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

No MULTIPLE CALL TO SEGMENT warning where it should be...

Alexander Sorockin

Please consider the following code.

//--- module main.c ---

...

void main() {
        ...
        set_status_word(...);
        ...
}

//--- module can.c ---

...

void CAN_int_handler(void) interrupt 7 {
        ...
        set_status_word(...);
        ...
}

//--- module utils.c ---

...

void set_status_word(...) {
        ...
}

If you replace the calls to set_status_word() with calls to printf(), the linker issues a "multiple call to segment" warning, but, like this, this code causes no warnings. Why not? I looked at the assembler output of the set_status_word() function and noticed that it isn't using absolute register addressing. Can this relate somehow?

Parents
  • 0

    What exactly does set_status_word() do ?

    If it is not using any overlayed memory (no local non-static variables, few enough parameters so they can be passed in registers), then the linker should not issue a warning.

    However, the lack of a warning does not mean that things can go awry. For example if the function modifies global variables. In this case, however, it is the programmers job to make sure that multiple calls of the function work correctly.

Reply
  • 0

    What exactly does set_status_word() do ?

    If it is not using any overlayed memory (no local non-static variables, few enough parameters so they can be passed in registers), then the linker should not issue a warning.

    However, the lack of a warning does not mean that things can go awry. For example if the function modifies global variables. In this case, however, it is the programmers job to make sure that multiple calls of the function work correctly.

Children
  • 0 in reply to Christoph Franck

    things can go awry

    things cannot go awry.

    Sorry about the typo.

  • 0 in reply to Christoph Franck 

    unsigned int status_word;

...

void set_status_word(unsigned int new_status_word)
{
    status_word = new_status_word;
}

    This should not give you an L15 error, since the function argument is passed in registers and the function has no local variables that are located in overlayed memory. The function is intrinsically reentrant. However:

    unsigned char array_idx;
unsigned char array_data[4];

void put_data_into_array(unsigned char input_data)
{
  if(array_idx < 4)
  {
    array_data[array_idx++] = input_data;
  }
}

    This doesn't produce an L15 error either, even though it is guaranteed to produce "unintended" behavior. It is the programmers job to recognize the potential source of trouble and eliminate it.

  • 0 in reply to Christoph Franck

    The function is intrinsically reentrant.

    *sigh* Ok, I wrote this too fast. This function can still result in a garbled value of status_word, because each of the two bytes is written individually. If there's an interrupt (with another call of set_status_word()) right after the first byte is written, status_word might get set to an erroneous value.

  • 0 in reply to Christoph Franck

    Christoph,

    Thanks for your response. Yes, set_status_word() just modifies status_word:

    unsigned char xdata status_word;

void set_status_word(unsigned char err, bit yes) {
        if (yes)
                status_word &= err;
        else
                status_word |= (~err & 0xF);
}

    The memory model is large, so the parameters are passed via XDATA:

    0014 900000      R     MOV     DPTR,#err
0017 E0                MOVX    A,@DPTR
0018 FF                MOV     R7,A
...

    Obviously, this can lead to unpredictable behaviour, can't it? *sigh* Ok, I wrote this too fast. This function can still result in a garbled value of status_word, because each of the two bytes is written individually. If there's an interrupt (with another call of set_status_word()) right after the first byte is written, status_word might get set to an erroneous value. All right, but what are the exact criteria the linker uses for deciding whether to issue or not to issue that message?

  • 0 in reply to Alexander Sorockin

    Obviously, this can lead to unpredictable behaviour, can't it?

    ... ohh yes. ;)

    All right, but what are the exact criteria the linker uses for deciding whether to issue or not to issue that message?

    Maybe the linker assumes that function arguments are passed in registers when they really aren't ?

    This could be a bug in the linker. Did you file a bug report ?

  • 0 in reply to Christoph Franck

    This forum doesn't seem to add new messages at the end... Never mind.


    This could be a bug in the linker. Did you file a bug report ?


    Not yet. First, I want to make sure it isn't my bug. Besides, it would be a second bug I found in Keil C. Too many for a single programmer, isn't it? ;-)