Tests hang when compiled for x86 but run fine in simulator for target uC

[MikeExMachina]

I'm trying to get a feel for how to write my code in way that it can be cross compiled (XC16 for pic24) and tested in the simulator, but also natively compiled to run a more expansive tool set on the code like gcvor and eventually things like sonarqube, valgrind, etc. My target platform is a PIC24 and I was delighted to see an example is provided. Actually, I'm using this slightly update fork, which works great when run as designed, using the microchip simulator.

I then tried to adapt it so that it would run natively outside of the simulator. I did this mainly by slimming down p24hj128GP202.h file included with the compiler to just the extern'd declerations necessary for the project to compile. Then I added a p24hj128GP202.c to effectively provide RAM based SFR definitions during native compilation, implemented like this:

#ifndef __XC__
#include "p24HJ128GP202.h"
volatile uint16_t LATA = 0;
volatile LATABITS LATAbits = {0};
volatile uint16_t LATB = 0;
volatile LATBBITS LATBbits = {0};
#endif

I then commented out the :tools: section of my project.yml so it would just use the default gcc. This leads to a project that compiles but hangs when attempting to run the unit tests like this:

Linking test_gpio_access.elf...
Running test_gpio_access.elf...
//hangs forever here

It's important to note that if I uncomment the tools section so that it complies with XC16 and executes in the microchip simulator, everything works as expected. I would really appreciate if anyone could help me understand where I'm going wrong here.

[Letme]

Hook up the gdb to the executable, but from afar that elf suffix is strange (should be .a or .exe). Also it coukd be that you are waiting for some register to flip, but it does not...

[MikeExMachina]

The elf extension was just a choice by the fork owner, and I believe that is the technically correct file format for the post linking binary output of gcc on linux

:extension:
  :executable: .elf

I ran the binary with gdb as you suggested.....it works?

(gdb) run
Starting program: /home/malan/CeedlingExample_Microchip/build/test/out/test_gpio_access.elf 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
test_gpio_access.c:22:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_A0:PASS
test_gpio_access.c:28:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_A1:PASS
test_gpio_access.c:34:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_A2:PASS
test_gpio_access.c:40:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_A3:PASS
test_gpio_access.c:46:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_A4:PASS
test_gpio_access.c:54:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_A0:PASS
test_gpio_access.c:64:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_A1:PASS
test_gpio_access.c:74:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_A2:PASS
test_gpio_access.c:84:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_A3:PASS
test_gpio_access.c:94:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_A4:PASS
test_gpio_access.c:107:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_B0:PASS
test_gpio_access.c:113:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_B1:PASS
test_gpio_access.c:119:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_B2:PASS
test_gpio_access.c:125:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_B3:PASS
test_gpio_access.c:131:test_GPIO_SetBit_should_set_corresponding_SFR_bit_for_B4:PASS
test_gpio_access.c:139:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_B0:PASS
test_gpio_access.c:149:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_B1:PASS
test_gpio_access.c:159:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_B2:PASS
test_gpio_access.c:169:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_B3:PASS
test_gpio_access.c:179:test_GPIO_ClearBit_should_clear_the_corresponding_SFR_bit_for_B4:PASS

-----------------------
20 Tests 0 Failures 0 Ignored 
OK

So why would I be getting stuck when running the test via ceedling test:all?

[Letme]

Ì will take another guess and ask you to check if there is any postprocessing of results because of what pic simulator returns? Because it might be reading a log file or waiting for some line on stdout/err to complete the processing...

[MikeExMachina]

Ì will take another guess and ask you to check if there is any postprocessing of results because of what pic simulator returns?

The simulator is the one that works, its the native build (with the test fixture commented out) that hangs. I'm noticing that in gdb even after the results and the 'OK' are printed, the process doesn't return in gdb, it's still running. Is that the expected behavior? The hang would make sense if it was waiting for test_gpio_access.elf to actually return before moving on to the next set of tests and its not returning, but if its completing all the tests then it can't be getting caught up inside any of them, where would it be getting stuck?

[MikeExMachina]

I figured it out, the example i'm using goes into a forever DeadLoop per the cross compilation guidance here once the tests are complete. The text fixture looks like it actually monitors the ouput for the "OK" and then effectively kills the process. Without that logic, the native build just got stuck in the DeadLoop. Changing this:

#ifndef UNITY_CONFIG_H
#define UNITY_CONFIG_H
#include "UnityHelper.h"
#define UNITY_OUTPUT_COMPLETE() UnityHelperDeadLoop()
#endif

to this

#ifndef UNITY_CONFIG_H
#define UNITY_CONFIG_H

#include "UnityHelper.h"
#ifdef __XC__
#define UNITY_OUTPUT_COMPLETE() UnityHelperDeadLoop()
#endif
#endif

Resolved my native build issues. Thanks @Letme for the help.

[Letme]

I am not sure what else that fork does, but such defines could be in project.yml and then it would not be needed to have a separate header just for this.