Why does calling a function in a particular implementation file cause GDB to no longer work?

[dave408]

I have an application where, as a test, I am calling an empty (nop-like) function in an implementation file from main().  If I don't call this function, GDB runs and I can step through my code in the debugger.  However, if I call the function (it can be any function, and can be empty and take no arguments!), then GDB will disconnect immediately.  It's reproducible 100% of the time.

I then tried to "run" the application, thinking that GDB stopping is causing my application to not work as well.  I added a task that would toggle a GPIO, confirmed it worked, and then added the call to Nop().  When I ran, the GPIO no longer worked, which indicates that the program is either not running, or it's halting.

I thought maybe something was messed up when linking in that implementation file.  I looked at the map file output and I didn't see anything strange.  I thought maybe the task's stack size was too small, so I increased it from 1k to 4k (even 1k seems like too much), but that didn't help, either.

I then reproduced the problem with the simplest application possible -- no MQX, just a baremetal project that calls my Nop function, and it still fails to run.

I've attached the program here in case anyone has time to look at it and tell me what I am missing here...  I don't understand what could have caused this, because I used an earlier version of this C file two weeks ago and was able to execute the functions calls fine!

Original Attachment has been moved to: L6470_k22f_deathtest.zip

[dave408]

This really concerns me -- I "fixed" the problem by commenting out all of the code except for the Nop(), confirmed that that worked, then I uncommented all of the code, and now everything works again.

Can anyone explain how this is possible?  This sort of stuff makes no sense to me, and it tends to drive me crazy.  :smileyhappy:

[dave408]

While this seems to have worked for the baremetal project, my "real" project that uses MQX still has the same problem.  If I call Nop(), it works.  If I add another function, say Nop2() and don't even call it, I can't debug my application.  This makes no sense (to me)!

[dave408]

I've figured out the cause of the problem.  I think this is a bug in something, I just don't know what.  Hopefully BlackNight can take a look at this?

I've narrowed the problem down to two things:

1.  Declaring and defining a function that is not called by any code

2.  Ordering of function definitions matters

In my application, I had removed all code from an implementation file and only left Nop(), which looks like this:

int Nop() { return 0; }

and in main, I called Nop().

I have Nop() prototyped in my header file like this:

int Nop();

Now, if I add a function to both called Nop2():

Header file:

int Nop2();

int Nop();

C file:

int Nop2() { return 0; }

int Nop() { return 0; }

and run my application with these changes, the debugger fails to start.

I then noticed that if I call Nop2() in main, the debugger does start.

I then removed the call to Nop2() in main, and moved the definition of Nop2() below Nop(), and the debugger starts fine.

I haven't gone back to compare map files between the different scenarios, but doesn't this all seem a bit strange?

[dave408]

This is so frustrating.  The problem is not reproducible as I had originally thought.  I loaded my sample project on another computer, and it worked just fine.

I cannot explain this behavior, but I have witnesses that this strange behavior did indeed occur!  :smileyhappy:

[BlackNight · Accepted solution]

Dave,

what is the log of gdb/debugger in the console view? Maybe this gives an indication what is going wrong?

Additionally, there is a known problem in GDB using breakpoints on non-existing code. Your description let me believe it could be related to that.

Can you remove all your breakpoints and watchpoints to be sure?

See Failed to Debug with GDB: Breakpoints or Expressions on non-existing Locations | MCU on Eclipse

I hope this helps,

Erich

[dave408]

Weird.  I tried deleting my breakpoints again today, and it *seems* that it worked this time!  I'll mark this as the correct answer unless it happens to come up again.  Very strange, but if that's what ended up fixing my issue, I'm happy!

[dave408]

Hi BlackNight​, sorry to bug you, but do you have any insight into the problem I'm experiencing?  I'm basically stuck and can't get my applications to run reliably.  It seems to me that disabling a task, regenerating the code, and then debugging should work.  I have mixed results where in some configurations, everything works, while other times some tasks run and not others, or GDB just exits prematurely.  Can you recommend any other FSL support members that might be able to give me appropriate next steps to determine the cause of this strange behavior?  Thank you!

[dave408]

Hi BlackNight, it's happened again in a different project, but might be slightly different since I'm unable to do anything to get the code to debug.

My MQX application calls into my EEPROM read/write code, for example something like this:

void Test_task(os_task_param_t task_init_data)
{
#ifdef PEX_USE_RTOS
  while (1) {
#endif

        uint16_t status;
        while(1) {
            TestNewEepromRead();
        }


#ifdef PEX_USE_RTOS  
  }
#endif   
}

int foo( uint32_t i, uint8_t *val)
{
    return 0;
}

void TestNewEepromRead()
{
    uint32_t max = pow( 2, 17);
    for( int i=0; i<max; i++) {
        uint8_t val;
        //int ret = foo( i, &val);
        int ret = Eeprom_Read( i, &val);
        /*
        assert( ret == 0);
        assert( val == 0xFF);
        */
    }
}

In my EEPROM C file, the code is completely commented out and just returns 0.

When I try to debug this program, GDB halts, but I'm able to capture the output stream if I copy and paste before the window is cleared.

SEGGER J-Link GDB Server V4.92 Command Line Version

JLinkARM.dll V4.92 (DLL compiled Sep 30 2014 09:33:42)

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      localhost only

Generate logfile:              off

Verify download:               on

Init regs on start:            on

Silent mode:                   off

Single run mode:               on

Target connection timeout:     5 sec.

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MK22FN512xxx12

Target interface:              SWD

Target interface speed:        30kHz

Target endian:                 little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link OpenSDA 2 compiled Nov 28 2014 10:35:51

Hardware: V1.00

S/N: 621000000

Checking target voltage...

Target voltage: 3.30 V

Listening on TCP/IP port 2331

Connecting to target...Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x00000000 (Data = 0x20010000)

Target interface speed set to 30 kHz

Resetting target

Halting target CPU...

...Target halted (PC = 0x00000410)

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000

R12= 00000000, R13= 20010000, MSP= 20010000, PSP= 00000000

R14(LR) = FFFFFFFF, R15(PC) = 00000410

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00

Reading all registers

Select auto target interface speed (1429 kHz)

Flash breakpoints enabled

Semi-hosting enabled (VectorAddr = 0x08)

Semihosting I/O set to TELNET Client

Read 4 bytes @ address 0x00000410 (Data = 0x49124811)

Downloading 1024 bytes @ address 0x00000000 - Verified OK

Downloading 16 bytes @ address 0x00000400 - Verified OK

Downloading 16144 bytes @ address 0x00000410 - Verified OK

Downloading 16144 bytes @ address 0x00004320 - Verified OK

Downloading 16092 bytes @ address 0x00008230 - Verified OK

Downloading 8 bytes @ address 0x0000C10C - Verified OK

Downloading 2188 bytes @ address 0x0000C114 - Verified OK

Read 4 bytes @ address 0x00000410 (Data = 0x49124811)

Read 2 bytes @ address 0x00000000 (Data = 0x0000)

Read 2 bytes @ address 0x00000002 (Data = 0x2001)

Read 2 bytes @ address 0x00000004 (Data = 0x0411)

Read 2 bytes @ address 0x00000006 (Data = 0x0000)

Read 2 bytes @ address 0x00000008 (Data = 0x0685)

Read 2 bytes @ address 0x0000000A (Data = 0x0000)

Read 2 bytes @ address 0x0000000C (Data = 0x0685)

Read 2 bytes @ address 0x0000000E (Data = 0x0000)

Read 2 bytes @ address 0x00000010 (Data = 0x0685)

Read 2 bytes @ address 0x00000012 (Data = 0x0000)

Read 2 bytes @ address 0x00000014 (Data = 0x0685)

Read 2 bytes @ address 0x00000016 (Data = 0x0000)

Read 2 bytes @ address 0x00000018 (Data = 0x0685)

Read 2 bytes @ address 0x0000001A (Data = 0x0000)

Read 2 bytes @ address 0x0000001C (Data = 0x0000)

Read 2 bytes @ address 0x0000001E (Data = 0x0000)

Read 2 bytes @ address 0x00000020 (Data = 0x0000)

Read 2 bytes @ address 0x00000022 (Data = 0x0000)

Read 2 bytes @ address 0x00000024 (Data = 0x0000)

Read 2 bytes @ address 0x00000026 (Data = 0x0000)

Read 2 bytes @ address 0x00000028 (Data = 0x0000)

Read 2 bytes @ address 0x0000002A (Data = 0x0000)

Read 2 bytes @ address 0x0000002C (Data = 0x0499)

Read 2 bytes @ address 0x0000002E (Data = 0x0000)

Read 2 bytes @ address 0x00000030 (Data = 0x0685)

Read 2 bytes @ address 0x00000032 (Data = 0x0000)

Read 2 bytes @ address 0x00000034 (Data = 0x0000)

Read 2 bytes @ address 0x00000036 (Data = 0x0000)

Read 2 bytes @ address 0x00000038 (Data = 0x051B)

Read 2 bytes @ address 0x0000003A (Data = 0x0000)

Read 2 bytes @ address 0x0000003C (Data = 0x0455)

Read 2 bytes @ address 0x0000003E (Data = 0x0000)

GDB closed TCP/IP connection

If I comment out the call into my EEPROM C file and just call foo, which has the exact same function signature as Eeprom_Read(), the debugger runs just fine.  So this makes me think there is something wrong with linking, but I'm not sure where to go from here.  I compared the two MAP files, but to me they look reasonable enough.  I've attached them to this post in case they are useful to you.

I've also looked at the output when the debugger works, and there is a lot more traffic over the J-Link connection, i.e. the "bad" scenario cuts off very early.  I attached the "good" GDB output as well.

Any assistance you can provide on this would be really appreciated, as I fear this might happen more and more as I continue to create applications.  Thank you!

[dave408]

Thanks, Erich, I'll have to try to reproduce the problem.  However, I might end up holding off on this for a little while until I experience it again!  I have to try to complete some tasks, so this might go on the backburner.  Thank you for providing that link to your blog.  I hadn't read that post yet!

The only extra information I can provide is that I created another task to toggle a GPIO.  When my code failed to debug, I then decided to "run" it by following the instructions you gave me on the forum today (disable breakpoint at main, add "monitor go" and "disconnect" to settings).  The GPIO did not toggle as it should, which led me to believe that the code was really not executing and somehow terminating completely.

We'll see how it goes tomorrow.  I'm going to just continue on as I was before I ran into this strange behavior, and if it appears again, I'll follow your steps.  Thanks again!

[dave408]

I should have brute force debugged this one.  If I comment out all of the code in my C file except for the Nop() function, then it debugs and runs okay.  So I just have to slowly uncomment functions to see when the wheels fall off.  Stay tuned...