• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 725 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

assert_istrue function variation

Kedar Josh
Prodigy 140 points

Is there any way I can change the way assert_istrue() works? Instead of just aborting at the point when the assert conditions fails, could a software breakpoint be setup there? It will be very useful for debugging. I am using unwind as the error policy. 

  • 0
    TI__Mastermind 37985 points

    Kedar,
    asserts always lead to program termination, no matter what the error policy is. The error policy matters only in cases where a caller passes an error block to a function that can possibly raise an error. There is no Assert API that would allow you to pass an error block.

    You can always put a breakpoint at Assert_raise__I function because each failed assert will go thorugh that function.

  • 0 in reply to Sasha Slijepcevic
    Genius 4750 points

    Sasha,

    "asserts always lead to program termination"

    is there a way to change this behavior ?

    the Assert module source code it calls "Error_raiseX" and Error_raiseX explicitely use the  Error policy.

    but as Assert calls Error raise with NULL as an error block
    Error_raiseX(NULL, mod, file, line,
            Assert_E_assertFailed, (IArg)sep, (IArg)msg);

    in Error.c it leads to the Error policy being bypassed.

    if (eb == NULL) {
            eb = &defErr;
        }

    if (Error_policy == Error_TERMINATE || eb == &defErr) {
            System_abort("xdc.runtime.Error.raise: terminating execution\n");
        }

    I would like to avoid hacking the assert.c or error.c source code.

    Is there a workaround ?

    Clement
    (tell me if I should open a new thread because this one is answered)

  • 0 in reply to Clement FR
    TI__Mastermind 37985 points

    As you can see in Assert.c, that NULL parameter is hardcoded so I can't see how to change that behavior without changing the actual code in C files. Alternatively, you could try using --symbol_map functionality in the TI linker to intercept all Assert_raise calls with your implementation of it.

    Which asserts are causing you trouble? It's possible we could find another solution if you can explain your problem in more details.

  • 0 in reply to Sasha Slijepcevic
    Genius 4750 points

    Nevermind, we'll accommodate this behavior in our design.

    We were wondering if it wasn't too hard on end-users of our library to get an abort each time an assert is raised.
    We decided that with good documentation it'll be fine.

    Clement