GCC cleanup-Funktion / longjmp

[STM32MP1 liebäugler (Gast)]

Hallo,

ich verwende das cleanup-Attribut des gcc um eine Interruptsperre bei 
verlassen des Scopes einer (Sperr)Variable wieder aufzuheben. Soweit 
funktioniert das auch. Wenn ich aber in einer Unterfunktion einen 
longjump() aufrufe, wird die Sperre nicht aufgehoben, da der Scope der 
Variable vermeitlich noch nicht verlassen ist. Gibt es eine Möglichkeit 
dem gcc mitzuteilen, dass eine Funktion zum verlassen des Scopes führt? 
__attribute__((noreturn)) führt nicht zum gewünschten Ergebnis.

Gruß

[Dr. Sommer (Gast)]

Mit Destruktoren und Exceptions (statt longjmp) in C++ geht das. 
Erfordert aber eine Menge Overhead. Ich würde longjmp soweit irgends 
möglich vermeiden, und Destruktoren statt Compiler spezifischer 
Attribute verwenden.

[STM32MP1 liebäugler (Gast)]

C++ Exceptions sind für µC doch ziemlich fett (Du schreibst es ja). Ich 
habe mit setjmp/longjump eine einfache Exceptionbehandlung in C 
implementiert. Es geht mir darum, Fehler (nicht irgendwelche Zustände 
wie z.B. in Java geläufig) auf jeden Fall zu behandeln. Über 
Rückgabewerte ist das Ganze nur bedingt zuverlässig, da man ja weiss, 
dass die Funktion immer funktioniert und der Wert dann auch nicht zu 
prüfen ist ;-)
Und jetzt bin auch das Problem im Zusammenhang mit longjmp gestossen. 
Den Komfort/Sicherheit welcher durch die "cleanup-Locks" erreicht wird, 
möchte ich nicht wieder missen.

[Dr. Sommer (Gast)]

Das Problem ist, dass man zum automatischen Bereinigen beim 
Herausspringen eine Menge Technik braucht - "personality functions", 
Exceptios Tabellen, Speicher Pools... Das gleiche was man halt auch bei 
Exceptions macht. Bei uC muss man da wohl in den sauren Apfel beißen und 
es händisch machen. Da hat man aber sowieso meistens keine derart tiefen 
Aufruf Stacks. Das Cleanup kann man mit Destruktoren oder teilweise auch 
Lambdas in C++ automatisieren, aber longjmp bringt einfach alles 
durcheinander...

[Markus F. (mfro)]

Das ist m.E. ein rein logisches Problem, kein Problem der Sprache. Auch 
C++-Exceptions und/oder Destruktoren können das nur verstecken, nicht 
beheben.

Wenn Du einen Mechanismus hast, der lediglich bei einem (geordneten) 
Verlassen einer Routine einen globalen Status aufhebt, mußt Du bei einem 
ungeordneten Verlassen (longjmp) eben selbst dafür sorgen, daß sauber 
aufgeräumt wird.

Wenn man sich schon in diese dunklen Gefilde hinabbegeben hat: sowas 
kann m.E. ein guter Grund für ein goto sein. Springt man mit goto aus 
einem Scope (der in deinem Fall die Variable mit dem cleanup Attribut 
enthalten könnte), wird der Stack noch abgeräumt. Das Sprungziel des 
gotos könnte dann dein longjmp() sein.

Allein, mir schaudert ob der Vorstellung ...

[Dr. Sommer (Gast)]

Markus F. schrieb:
> Auch C++-Exceptions und/oder Destruktoren können das nur verstecken,
> nicht beheben.
>
> Wenn Du einen Mechanismus hast, der lediglich bei einem (geordneten)
> Verlassen einer Routine einen globalen Status aufhebt, mußt Du bei einem
> ungeordneten Verlassen (longjmp) eben selbst dafür sorgen, daß sauber
> aufgeräumt wird.

Die Idee war ja, Exceptions statt longjmp zu nutzen. Die Grundidee ist 
artverwandt, aber der Compiler kann dies geordnet umsetzen und eben 
Destruktoren aufrufen. Nur leider ist mindestens die Implementation vom 
GCC+newlib nicht wirklich uC-tauglich. Es wäre interessant da etwas 
geeignetes zu implementieren, das wäre aber ein beträchtlicher Aufwand. 
Realistisch wäre es, longjmp wegzulassen, und mit Rückgabewerten 
(Fehlercodes) und Destruktoren zu arbeiten. Das C++ Attribut "nodiscard" 
oder die GCC Erweiterung __attribute__((warn_unused_result)) können da 
helfen Fehler zu vermeiden.

[Nop (Gast)]

Innerhalb eines Blocks, wo Ressourcenallokation stattgefunden hat, setzt 
man grundsätzlich kein longjmp ein, das ist ein Antipattern.

[Markus F. (mfro)]

Ich habe das so verstanden: der TO hat jetzt so was:

void cleanup(void *lock)
{
    *lock = unlocked;
}

void function_may_fail(void)
{
    void *global_lock __attribute__((cleanup));
    bool failed = false;
    
    *global_lock = locked;

    /* mach was */

    failed = ...

    if (failed) longjmp(jbf);

    ...
}

Wenn ein Fehler auftritt, der zum longjmp() führt, wird die 
cleanup()-Funktion nicht ausgeführt. Mein Vorschlag wäre so was:

void cleanup(void *lock)
{
    *lock = unlocked;
}

void function_may_fail(void)
{
    do {
        void *global_lock __attribute__((cleanup));
        bool failed = false;
    
        *global_lock = locked;

        /* mach was */
        failed = ...

        if (failed) goto fail;

        return;
    } while (false);    

fail:
    longjmp(jbf);
}

Das müsste (ich hab's nicht ausprobiert) m.E. wie gewünscht 
funktionieren. Ist nicht schön, aber das ist longjmp() nie...

[Dr. Sommer (Gast)]

Die m.M.n saubersten Versionen wären so (es ging ja um 
Interrupt-Sperren):

class IrqLocker {
  public:
    IrqLocker () { __disable_irq (); }
    ~IrqLocker () { __enable_irq (); }
    IrqLocker (const IrqLocker&) = delete;
    IrqLocker (IrqLocker&&) = delete;
    IrqLocker& operator = (const IrqLocker&) = delete;
    IrqLocker& operator = (IrqLocker&&) = delete;
};

bool machwas ();

void function_may_fail(void)
{
    IrqLocker irqLock;

    bool failed = !machwas ();
    if (failed) throw std::runtime_error ("faild");
}

oder mit Lambdas

template <typename F>
auto irqLock (F&& f) -> decltype (std::forward<F> (f) ()) {
  __disable_irq ();
  auto res = std::forward<F> (f) ();
  __disable_irq ();
  return res;
}

void function_may_fail(void)
{
    irqLock ([&] () {
        bool failed = !machwas ();
        if (failed) throw std::runtime_error ("faild");
    }
}

Der Programmfluss ist hier ähnlich wie longjmp und ziemlich nah an dem, 
was ursprünglich gewünscht war, aber eben mit automatischem Aufräumen. 
Aber es ist standardisiert und braucht keine Compiler-spezifischen 
Attribute. Nur leider ist eben der Overhead dafür riesig. Daher würde 
ich die Fehlerbehandlung manuell machen:

class IrqLocker {
  public:
    IrqLocker () { __disable_irq (); }
    ~IrqLocker () { __enable_irq (); }
    IrqLocker (const IrqLocker&) = delete;
    IrqLocker (IrqLocker&&) = delete;
    IrqLocker& operator = (const IrqLocker&) = delete;
    IrqLocker& operator = (IrqLocker&&) = delete;
};

[[nodiscard]] bool machwas ();

[[nodiscard]] bool function_may_fail(void)
{
    IrqLocker irqLock;

    bool failed = !machwas ();
    if (failed) return false;
    ...
    return true;
}

Oder mit Lambdas:

template <typename F>
auto irqLock (F&& f) -> decltype (std::forward<F> (f) ()) {
  __disable_irq ();
  auto res = std::forward<F> (f) ();
  __disable_irq ();
  return res;
}

[[nodiscard]] bool machwas ();

[[nodiscard]] bool function_may_fail(void)
{
    return irqLock ([&] () {

        bool failed = !machwas ();
        if (failed) return false;
        ...
        return true;
    });
}

Mittels "nodiscard" sorgt man dafür, dass man die Auswertung der 
Rückgabe (Fehler-) Codes nicht vergisst. Die Interrupts werden immer 
automatisch ge-und entsperrt. Der Programmlauf ist anders als bei 
longjmp, es ist mehr Tipparbeit, aber dafür sauberer, lesbarer und auch 
standardisiert.

[DPA (Gast)]

Markus F. schrieb:
> Das müsste (ich hab's nicht ausprobiert) m.E. wie gewünscht
> funktionieren. Ist nicht schön, aber das ist longjmp() nie...

Das kann man so aber schlecht machen, wenn das longjmp nicht noch in 
irgend einer Unterfunktion ist, und sonst braucht man das nicht 
wirklich. Würde ich sowas machen, würde ich das so irgendwie machen:

// utils.h
#ifndef UTILS_H
#define UTILS_H

#include <setjmp.h>
#include <string.h>

#ifndef UNPACK
#define UNPACK(A) A
#endif

#define AUTOCLEANUP_FUNC(N,X) \
  typedef struct { \
    jmp_buf ac_jmp; \
    UNPACK X \
  } ac_ ## N ##_t; \
  static inline void ac_ ## N ## _func_sub(ac_ ## N ##_t* ac); \
  void ac_ ## N ## _func(ac_ ## N ##_t* ac){ \
    memcpy(&ac_next_jmp,&ac->ac_jmp,sizeof(ac->ac_jmp)); \
    ac_ ## N ## _func_sub(ac); \
  } \
  static inline void ac_ ## N ## _func_sub(ac_ ## N ##_t* ac)

#define AUTOCLEANUP(N,ID) \
  __attribute__((cleanup(ac_ ## N ## _func))) ac_ ## N ##_t ID; \
  memset(&ID, 0, sizeof(ID)); \
  if(memcmp(&ac_next_jmp, &ac_unset_jmp, sizeof(ac_unset_jmp))){ \
    memcpy(&ID.ac_jmp, &ac_next_jmp, sizeof(ac_next_jmp)); \
    if(setjmp(ac_next_jmp)){ \
      ac_ ## N ## _func(&ID); \
      longjmp(ac_next_jmp, 1); \
    } \
  }

#define AUTOCLEANUP_FINAL_ENDPOINT if(setjmp(ac_next_jmp))

#define AUTOCLEANUP_BACKOUT \
  ((memcmp(&ac_next_jmp, &ac_unset_jmp, sizeof(ac_unset_jmp)) && (longjmp(ac_next_jmp,1),1)), 1)

extern jmp_buf ac_next_jmp;
extern const jmp_buf ac_unset_jmp;

#endif

// utils.c
jmp_buf ac_next_jmp;
const jmp_buf ac_unset_jmp;

// example.c
#include <stdio.h>
#include <stdlib.h>

AUTOCLEANUP_FUNC(test_cleanup, (
  int a;
  int b;
)){
  printf("test_cleanup:  a: %d  b: %d\n", ac->a, ac->b);
}

void bla(void){
  if(AUTOCLEANUP_BACKOUT)
    abort(); // There never was a AUTOCLEANUP_FINAL_ENDPOINT
}

void test(void){
  AUTOCLEANUP(test_cleanup, c)
  c.a = 1;
  c.b = 2;
  bla();
}

int main(){
  AUTOCLEANUP_FINAL_ENDPOINT {
    printf("Backout, bye!!!\n");
    return 1;
  }
  test();
  printf("Nooo, I want to say something!!!\n");
  return 0;
}

Hab das jetzt aber nicht allzu ausgiebig getestet.

Eventuell könnte auch 
https://github.com/guillermocalvo/exceptions4c#lightweight-version 
interessant sein.