OpenOCD thread support and chSysInit visibility

[cooperised]

Hi all,

I'm trying to use GDB and OpenOCD to get thread-aware debugging of a ChibiOS/RT project. Right now I'm using OpenOCD 0.9.0 (2016-03-03) and the unmodified STM32F4DISCOVERY demo project from Chibios 16.1.4. I have configured OpenOCD to be RTOS-aware, first by using -rtos auto (which failed to detect an RTOS) and then by using -rtos ChibiOS. The registry is enabled in the project, as it is by default.

Using -rtos ChibiOS, OpenOCD now reports "Warn: RTOS ChibiOS not detected. (GDB could not find symbol 'chSysInit')". It seems that OpenOCD uses this symbol as a marker to indicate the presence of ChibiOS (OpenOCD's src/rtos/ChibiOS.c:141 has a comment that says "Necessary part of API, used for ChibiOS detection").

Investigating build/ch.elf using arm-none-eabi-gcc-nm reveals that this symbol is indeed missing, though the 'cb' and 'cb_debug' symbols that actually carry useful information are there. The 'chSysInit' symbol is present in build/obj/chsys.o though, and is also shown as imported by build/obj/main.o as expected. How come it doesn't show up in ch.elf? I can't see anything in the linker scripts (an export list, for example) or any decoration in the source code that forces internal visibility, but I guess there must be something!

Has anyone else encountered this?

Thanks!
Andy

[Giovanni]

Hi,

Relying on that symbol is not a good idea, LTO can remove the symbol because everything is inlined. Try disabling LTO in the makefile for confirmation.

Giovanni

[cooperised]

Thanks Giovanni. That makes perfect sense and indeed disabling LTO does remove that warning. I'll file a bug report against OpenOCD to remove the reliance on this symbol (and perhaps I'll then patch it and issue a pull request ).

Unfortunately it generates an error instead: "Memory signature does not contain magic bytes \ Reading the memory signature of Chibios/RT failed". Looking at the OpenOCD source it's expecting the four bytes "main" to exist at the start of the ch_debug block (if I'm reading it right). Has something changed or am I doing something dumb?

Thanks for your help!
Andy

[Giovanni]

Hi,

No changes there:

Code: Select all

/*
 * OS signature in ROM plus debug-related information.
 */
ROMCONST chdebug_t ch_debug = {
  {'m', 'a', 'i', 'n'},
  (uint8_t)0,
  (uint8_t)sizeof (chdebug_t),
  (uint16_t)(((unsigned)CH_KERNEL_MAJOR << 11U) |
             ((unsigned)CH_KERNEL_MINOR << 6U) |
             ((unsigned)CH_KERNEL_PATCH << 0U)),
  (uint8_t)sizeof (void *),
  (uint8_t)sizeof (systime_t),
  (uint8_t)sizeof (thread_t),
  (uint8_t)_offsetof(thread_t, p_prio),
  (uint8_t)_offsetof(thread_t, p_ctx),
  (uint8_t)_offsetof(thread_t, p_newer),
  (uint8_t)_offsetof(thread_t, p_older),
  (uint8_t)_offsetof(thread_t, p_name),
#if CH_DBG_ENABLE_STACK_CHECK == TRUE
  (uint8_t)_offsetof(thread_t, p_stklimit),
#else
  (uint8_t)0,
#endif
  (uint8_t)_offsetof(thread_t, p_state),
  (uint8_t)_offsetof(thread_t, p_flags),
#if CH_CFG_USE_DYNAMIC == TRUE
  (uint8_t)_offsetof(thread_t, p_refs),
#else
  (uint8_t)0,
#endif
#if CH_CFG_TIME_QUANTUM > 0
  (uint8_t)_offsetof(thread_t, p_preempt),
#else
  (uint8_t)0,
#endif
#if CH_DBG_THREADS_PROFILING == TRUE
  (uint8_t)_offsetof(thread_t, p_time)
#else
  (uint8_t)0
#endif
};

The symbol is only present if CH_CFG_USE_REGISTRY is enabled in chconf.h.

Giovanni

[cooperised]

Hmm, interesting, thank you. The ch_debug symbol is definitely present (OpenOCD would fail sooner if not) but the bytes it's reading are not correct. I'll do some more sleuthing today when I get the chance and report back.

Debugging OpenOCD was not on my to-do list for the week! Oh well...

Andy

[cooperised]

Ok, the signature mismatch was entirely my fault - it works this morning, and I think last night I probably just forgot to load the correct binary onto the target, so the ELF files known to gdb and OpenOCD were different.

I plan to file the bug report against OpenOCD as described. Removing the check on the presence of the 'chSysInit' symbol allows it to work just fine with LTO enabled. However, I wondered if you'd have any suggestions for a replacement symbol? I can understand the developer's motivation: without chSysInit, ChibiOS detection relies only on detecting a single exported symbol with a two-character name ('ch'). I guess they thought that might generate false positives with -rtos auto. Is there any other symbol that's guaranteed to be visible that OpenOCD could use instead of chSysInit for more robust detection? If so, I'll include that information in the bug report.

Many thanks,
Andy

[Giovanni]

Hi,

The symbol could be ch_debug, it identifies ChibiOS with registry enabled.

Giovanni

[cooperised]

Thanks Giovanni.

OpenOCD already looks for ch_debug in fact. The relevant code is

Code: Select all

if ((target->rtos->symbols != NULL) &&
        ((target->rtos->symbols[ChibiOS_VAL_rlist].address != 0) ||
         (target->rtos->symbols[ChibiOS_VAL_ch].address != 0)) &&
        (target->rtos->symbols[ChibiOS_VAL_chSysInit].address != 0)) {
    if (target->rtos->symbols[ChibiOS_VAL_ch_debug].address == 0) {
        LOG_INFO("It looks like the target is running ChibiOS without "
            "ch_debug.");
        return 0;
    }
    /* looks like ChibiOS with memory map enabled. */
    return 1;
}

So either rlist (ChibiOS 2.x) or ch (ChibiOS 3.x) is required, in addition to chSysInit; and then if ch_debug is undefined, detection will fail with a log message. My own opinion is that this should be robust enough even with chSysInit removed from the criteria, given that the lack of ch_debug results in a failed detection. We'll have to see whether the OpenOCD devs agree. If there was another symbol guaranteed to show up in the binary that could be used for detection in place of chSysInit, I'd suggest using it instead.

Andy

[cooperised]

Just FYI, I've submitted a bug report (#121) to OpenOCD, and then a patch to address the bug report (change 3381) which is currently in code review. Hopefully the next version of OpenOCD will support ChibiOS without having to disable LTO.

Andy

[Giovanni]

Thanks for the fix.

Giovanni