RE: Symbol tables, ELF binaries, and mksymtab
> -Original Message- > From: Byron Ellacott > Sent: Friday, March 12, 2021 9:02 PM > To: dev@nuttx.apache.org > Subject: Symbol tables, ELF binaries, and mksymtab > > Hi, > > I've been working on ELF binary loading for the eZ80. I'm compiling with > CONFIG_SYSTEM_NSH=m to produce a stand-alone nsh binary. > > I'm finding the symbol tables (both the one generated in libs/libc with > CONFIG_EXECFUNCS_SYSTEM_SYMTAB=y and the one generated in > apps) to be wrong when it comes to C functions having a prepended underscore > - the system symtab doesn't prepend an underscore, so all > symbol lookups fail. > The apps symtab does prepend an underscore to its "extern" definitions, so > any use of that symbol table fails with undefined external > references. > > Is this a configuration issue on my end? > No, it seem that mksymtab forget to handle the case you described. > I've modified tools/mksymtab to (a) prepend an underscore to the symbol's > name, and (b) prepend an "&" to the symbol's value. The latter > change allows exporting global variables like optarg and optind - I've also > added a number of missing symbols to syscall/syscall.csv and > libs/libc/libc.csv. > > I can now boot a NuttX kernel with no shell and successfully execute nsh from > SD card after my changes, but before I start making PRs I'd > like to understand if the difficulties I've faced are a PEBKAC issue or > something others encounter. > Most people try ELF loader on ARM and RISCV platform, both don't pretend an underscore to the symbol's name. So you may the first people encounter this mismatch issue☹. > (I'll also be contributing the Z80 elf loader, but it's not useful if you're > using ZDS-II.) > > -- > Byron
Tasks software watchdog timer
Hi everybody! I am in need of per-task software watchdog timers. I would like to somehow monitor my tasks, and ensure that they are running as they should. (For example, not stuck in an infinite loop). For this purpose, I usually use software implementations of watchdog timers. Note that by this, I do not mean the watchdogs that Nuttx already has, rather something similar to the hardware watchdog timer that most MCUs have. Each task should have a timer, which needs to be reset (feed) periodically so it does not expire. If it does, the offending task is terminated, or the system is restarted. As far as I can tell, NuttX does not have such a facility to monitor the execution of its tasks. (Or does it?) Is there any interest in adding this feature? I was thinking it like this: - Adding a timer in struct tcb_s. - Extend the sched() function to start, stop, configure and feed the watchdog. What do you think?
Re: Symbol tables, ELF binaries, and mksymtab
No, it seem that mksymtab forget to handle the case you described. This was handled in the past, but I forget where the logic was. Let me look around a bit. ... after a bit ... Googling, I find that there was some handling in the simulator for Cygwin. Some older tool toolchains did prepend the underscore character to the symbol name. Look at CONFIG_SIM_CYGWIN_DECORATED. 46 config SIM_CYGWIN_DECORATED 47 bool "Decorated Cygwin names" 48 default n 49 depends on WINDOWS_CYGWIN 50 ---help--- 51 Older versions of Cygwin tools decorated C symbol names by adding an 52 underscore to the beginning of the symbol name. Newer versions of 53 Cygwin do not seem to do this. 54 55 How do you know if you need this option? You could look at the generated 56 symbol tables to see if there are underscore characters at the beginning 57 of the symbol names. Or, if you need this option, the simulation will not 58 run: It will crash early, probably in some function due to the failure to 59 allocate memory. Currently that appears only at: * arch/sim/Kconfig:config SIM_CYGWIN_DECORATED * arch/sim/src/nuttx-names.in: (defined(CONFIG_HOST_WINDOWS) && defined(CONFIG_SIM_CYGWIN_DECORATED)) * boards/sim/sim/README.txt: CONFIG_SIM_CYGWIN_DECORATED=n * boards/sim/sim/README.txt: do not seem to do this. Deselecting CONFIG_SIM_CYGWIN_DECORATED will Which I think is insufficient. Probably some of the support was removed? I was thinking that there was a similar underscore issue with older SDCC toolchains, but I can't find anything now (except some references in arch/z80/src/Makefile.sdccw).
Re: Symbol tables, ELF binaries, and mksymtab
Which I think is insufficient. Probably some of the support was removed? No.. It is just that there was no support for loadable modules for those older Cygwin toolchains. The underscore has not been used with Cygwin since around 2015 so I think would be safe to just remove the CONFIG_SIM_CYGWIN_DECORATED configuration. In your case, I think you have two options: 1) Write a tool to rename all of the symbols in the library to remove the leading underscore (using objcopy --redefine-syms), or 2) Modify the elf loader[s] to conditionally prepend the '_' character before looking up the symbol by name.
Re: Tasks software watchdog timer
Why not to use the hardware watchdog timer which is more reliable and simple than the pure software solution? On Sun, Mar 14, 2021 at 5:49 AM Fotis Panagiotopoulos wrote: > Hi everybody! > > I am in need of per-task software watchdog timers. > I would like to somehow monitor my tasks, and ensure that they are running > as they should. > (For example, not stuck in an infinite loop). > > For this purpose, I usually use software implementations of watchdog > timers. > Note that by this, I do not mean the watchdogs that Nuttx already has, > rather something similar to the hardware watchdog timer that most MCUs > have. > > Each task should have a timer, which needs to be reset (feed) periodically > so it does not expire. > If it does, the offending task is terminated, or the system is restarted. > > As far as I can tell, NuttX does not have such a facility to monitor the > execution of its tasks. (Or does it?) > > Is there any interest in adding this feature? > > I was thinking it like this: > - Adding a timer in struct tcb_s. > - Extend the sched() function to start, stop, configure and feed the > watchdog. > > What do you think? >
Re: Tasks software watchdog timer
> Why not to use the hardware watchdog timer which is more reliable and > simple than the pure software solution? I do use it, but a hardware watchdog can monitor only one thing (in my case the kernel itself). I would like to monitor multiple things independently, the system's tasks. Στις Κυρ, 14 Μαρ 2021 στις 5:22 μ.μ., ο/η Xiang Xiao < xiaoxiang781...@gmail.com> έγραψε: > Why not to use the hardware watchdog timer which is more reliable and > simple than the pure software solution? > > On Sun, Mar 14, 2021 at 5:49 AM Fotis Panagiotopoulos > > wrote: > > > Hi everybody! > > > > I am in need of per-task software watchdog timers. > > I would like to somehow monitor my tasks, and ensure that they are > running > > as they should. > > (For example, not stuck in an infinite loop). > > > > For this purpose, I usually use software implementations of watchdog > > timers. > > Note that by this, I do not mean the watchdogs that Nuttx already has, > > rather something similar to the hardware watchdog timer that most MCUs > > have. > > > > Each task should have a timer, which needs to be reset (feed) > periodically > > so it does not expire. > > If it does, the offending task is terminated, or the system is restarted. > > > > As far as I can tell, NuttX does not have such a facility to monitor the > > execution of its tasks. (Or does it?) > > > > Is there any interest in adding this feature? > > > > I was thinking it like this: > > - Adding a timer in struct tcb_s. > > - Extend the sched() function to start, stop, configure and feed the > > watchdog. > > > > What do you think? > > >
Re: Tasks software watchdog timer
On Sun, Mar 14, 2021 at 8:27 AM Fotis Panagiotopoulos wrote: > > Why not to use the hardware watchdog timer which is more reliable and > > simple than the pure software solution? > > I do use it, but a hardware watchdog can monitor only one thing (in my case > the kernel itself). > > If you want to catch some task/thread in an infinite loop, the hardware watchdog monitor in nuttx can do it for you. > I would like to monitor multiple things independently, the system's tasks. > > > Στις Κυρ, 14 Μαρ 2021 στις 5:22 μ.μ., ο/η Xiang Xiao < > xiaoxiang781...@gmail.com> έγραψε: > > > Why not to use the hardware watchdog timer which is more reliable and > > simple than the pure software solution? > > > > On Sun, Mar 14, 2021 at 5:49 AM Fotis Panagiotopoulos < > f.j.pa...@gmail.com > > > > > wrote: > > > > > Hi everybody! > > > > > > I am in need of per-task software watchdog timers. > > > I would like to somehow monitor my tasks, and ensure that they are > > running > > > as they should. > > > (For example, not stuck in an infinite loop). > > > > > > For this purpose, I usually use software implementations of watchdog > > > timers. > > > Note that by this, I do not mean the watchdogs that Nuttx already has, > > > rather something similar to the hardware watchdog timer that most MCUs > > > have. > > > > > > Each task should have a timer, which needs to be reset (feed) > > periodically > > > so it does not expire. > > > If it does, the offending task is terminated, or the system is > restarted. > > > > > > As far as I can tell, NuttX does not have such a facility to monitor > the > > > execution of its tasks. (Or does it?) > > > > > > Is there any interest in adding this feature? > > > > > > I was thinking it like this: > > > - Adding a timer in struct tcb_s. > > > - Extend the sched() function to start, stop, configure and feed the > > > watchdog. > > > > > > What do you think? > > > > You don't need a special timer here, the posix timer can work very well: 1. Create a watchdog timer by timer_create 2. Feed the timer periodically through timer_settime 3. Register a timeout signal handler 4. Call exit/abort in signal handler >
Re: Tasks software watchdog timer
On 2021-03-14 17:36, Xiang Xiao wrote: On Sun, Mar 14, 2021 at 8:27 AM Fotis Panagiotopoulos wrote: Why not to use the hardware watchdog timer which is more reliable and simple than the pure software solution? I do use it, but a hardware watchdog can monitor only one thing (in my case the kernel itself). If you want to catch some task/thread in an infinite loop, the hardware watchdog monitor in nuttx can do it for you. Of course. But it will not be easy to do if you want to watch multiple threads. Because the hardware watchdog is very binary. If any thread were to kick the watchdog, it will not do a reset. So if one thread is hung, but others still run, your hardware watchdog will not do what you want, possibly. Not to mention that from a diagnistics point of view, it could be nice to be informed which thread was hung as well, as a part of the handling/restarting. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Tasks software watchdog timer
> If you want to catch some task/thread in an infinite loop, the hardware > watchdog monitor in nuttx can do it for you. If the hardware watchdog is fed from multiple sources, all of them need to fail. Not just one of them. Do you have anything else in mind? > You don't need a special timer here, the posix timer can work very well: > >1. Create a watchdog timer by timer_create >2. Feed the timer periodically through timer_settime >3. Register a timeout signal handler >4. Call exit/abort in signal handler This is a nice idea, thank you. I didn't think of it before. Στις Κυρ, 14 Μαρ 2021 στις 6:36 μ.μ., ο/η Xiang Xiao < xiaoxiang781...@gmail.com> έγραψε: > On Sun, Mar 14, 2021 at 8:27 AM Fotis Panagiotopoulos > > wrote: > > > > Why not to use the hardware watchdog timer which is more reliable and > > > simple than the pure software solution? > > > > I do use it, but a hardware watchdog can monitor only one thing (in my > case > > the kernel itself). > > > > > If you want to catch some task/thread in an infinite loop, the hardware > watchdog monitor in nuttx can do it for you. > > > > I would like to monitor multiple things independently, the system's > tasks. > > > > > > Στις Κυρ, 14 Μαρ 2021 στις 5:22 μ.μ., ο/η Xiang Xiao < > > xiaoxiang781...@gmail.com> έγραψε: > > > > > Why not to use the hardware watchdog timer which is more reliable and > > > simple than the pure software solution? > > > > > > On Sun, Mar 14, 2021 at 5:49 AM Fotis Panagiotopoulos < > > f.j.pa...@gmail.com > > > > > > > wrote: > > > > > > > Hi everybody! > > > > > > > > I am in need of per-task software watchdog timers. > > > > I would like to somehow monitor my tasks, and ensure that they are > > > running > > > > as they should. > > > > (For example, not stuck in an infinite loop). > > > > > > > > For this purpose, I usually use software implementations of watchdog > > > > timers. > > > > Note that by this, I do not mean the watchdogs that Nuttx already > has, > > > > rather something similar to the hardware watchdog timer that most > MCUs > > > > have. > > > > > > > > Each task should have a timer, which needs to be reset (feed) > > > periodically > > > > so it does not expire. > > > > If it does, the offending task is terminated, or the system is > > restarted. > > > > > > > > As far as I can tell, NuttX does not have such a facility to monitor > > the > > > > execution of its tasks. (Or does it?) > > > > > > > > Is there any interest in adding this feature? > > > > > > > > I was thinking it like this: > > > > - Adding a timer in struct tcb_s. > > > > - Extend the sched() function to start, stop, configure and feed the > > > > watchdog. > > > > > > > > What do you think? > > > > > > > > You don't need a special timer here, the posix timer can work very well: > >1. Create a watchdog timer by timer_create >2. Feed the timer periodically through timer_settime >3. Register a timeout signal handler >4. Call exit/abort in signal handler > > > >
Re: Tasks software watchdog timer
On Sun, Mar 14, 2021 at 9:40 AM Johnny Billquist wrote: > On 2021-03-14 17:36, Xiang Xiao wrote: > > On Sun, Mar 14, 2021 at 8:27 AM Fotis Panagiotopoulos < > f.j.pa...@gmail.com> > > wrote: > > > >>> Why not to use the hardware watchdog timer which is more reliable and > >>> simple than the pure software solution? > >> > >> I do use it, but a hardware watchdog can monitor only one thing (in my > case > >> the kernel itself). > >> > >> > > If you want to catch some task/thread in an infinite loop, the hardware > > watchdog monitor in nuttx can do it for you. > > Of course. But it will not be easy to do if you want to watch multiple > threads. Because the hardware watchdog is very binary. If any thread > were to kick the watchdog, it will not do a reset. So if one thread is > hung, but others still run, your hardware watchdog will not do what you > want, possibly. > > You don't need kick the watchdog from userspace, but watchdog monitor will: 1. Kick the watchdog from idle thread(WATCHDOG_AUTOMONITOR_BY_IDLE=y) 2. Kick the watchdog from work thread(WATCHDOG_AUTOMONITOR_BY_WORKER=y) 3. Kick the watchdog from timer interrupt(WATCHDOG_AUTOMONITOR_BY_TIMER=y) 4. Kick the watchdog from watchdog interrupt(WATCHDOG_AUTOMONITOR_BY_CAPTURE=y) The different kick strategy can find the different problem: 1. WATCHDOG_AUTOMONITOR_BY_IDLE find any busy loop in long time 2. WATCHDOG_AUTOMONITOR_BY_WORKER find some worker blocking the work queue 3. WATCHDOG_AUTOMONITOR_BY_TIMER find the interrupt mask for long time You can find more detail from the code: https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/watchdog.c Not to mention that from a diagnistics point of view, it could be nice > to be informed which thread was hung as well, as a part of the > handling/restarting. > >Johnny > > -- > Johnny Billquist || "I'm on a bus >|| on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol >
Re: Tasks software watchdog timer
Of course. But it will not be easy to do if you want to watch multiple threads. Because the hardware watchdog is very binary. If any thread were to kick the watchdog, it will not do a reset. So if one thread is hung, but others still run, your hardware watchdog will not do what you want, possibly. I have using an approach in the past where each thread indicates that it wants to reset the watchdog (by, say, setting a bit in a global bitset or sending a messages to a "master" thread). The hardware is not actually reset until all participating threads have requested the reset. If one thread hangs, there is no reset and the watchdog will expire. You an also see which thread was the culprit.
Re: Tasks software watchdog timer
On 2021-03-14 19:27, Gregory Nutt wrote: Of course. But it will not be easy to do if you want to watch multiple threads. Because the hardware watchdog is very binary. If any thread were to kick the watchdog, it will not do a reset. So if one thread is hung, but others still run, your hardware watchdog will not do what you want, possibly. I have using an approach in the past where each thread indicates that it wants to reset the watchdog (by, say, setting a bit in a global bitset or sending a messages to a "master" thread). The hardware is not actually reset until all participating threads have requested the reset. If one thread hangs, there is no reset and the watchdog will expire. You an also see which thread was the culprit. Yeah. I've been doing something like that as well. Seems like a reasonable solution, which gives all the functions I like, while still possible to keep very simple. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
