Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

std::tuple + arm-none-eabi-g++ v8.3.1 = brak możliwości debugowania ?

12 Gru 2019 08:41 237 5
  • Poziom 5  
    Witam,

    W moim kodzie chciałbym skorzystać z dobrodziejstwa std::tuple oraz std::apply (wszystko to dostępne pod #include <tuple>).

    Po umieszczeniu tej dyrektywy w kodzie, program prawidłowo się kompiluje oraz (o dziwo !) prawidłowo działa, jednak moje środowisko (DS-5 od ARM) przestaje poprawnie debugować (brak zmiennych lokalnych w oknie Variables, podczas debugowania program nie chce wystartować od symbolu main - manualnie trzeba przestawiać PC na 0x00000000 etc.) - być może coś z sekcjami .debug_* ?

    Kompilacja to nic specjalnego czyli -O0 -g -std=c++1z
    Linkowanie to --specs=nosys.specs -nostartfiles -T ${CMAKE_SOURCE_DIR}/linker/script.ld

    Czy tutaj może chodzić np o skrypt linkera ? (pojawienie się tupli w kodzie powoduje powstanie jakiejś magicznej sekcji której nie uwzględniam)

    Jeżeli ktoś z kolegów spotkał się z podobnym problemem proszę o jakąś wskazówkę. W razie czego służę dumpami.

    @edit:
    jedyne co udało mi się ustalić to to, iż w przypadku załączenia <tuple>, w sekcji *text, przed funkcją main pojawia się tajemnicza funkcja _ZL20__gthread_key_delete

    Pozdrawiam
  • Specjalista - Mikrokontrolery
    Jeśli w tym środowisku użyte jest GDB, to w zasadzie jedyne co możesz zrobić to włączyć "pretty printing". Spróbowałbym też bez `-nostartfiles` dla linkera, bo ta opcja może niezbyt dobrze zadziałać z C++. W ramach experymentów możesz też spróbować z -Og zamiast -O0, oraz sprawdzić co by było bez `--specs=...`.

    Generalnie używam w kodzie tych dwóch konstruktów i nie zauważyłem nigdy specjalnych problemów przy debuggerze, no ale to inne środowisko (akurat teraz Visual Studio Code, ale w Eclipse tak samo bez problemów) i inny skrypt linkera (jeśli ma faktycznie jakieś znaczenie).
  • Poziom 5  
    Moje środowisko (a właściwie output debugera podczas ładowania) podpowiada, że może chodzić o sekcje .debug_info:

    ! Section .debug_info offset 845: Error while parsing debug information
    ! Failed to demand load DWARF debugging information: section .debug_info, offset 0x845
    ! Failed to demand load DWARF debugging information: section .debug_info, offset 0x845

    Po dodaniu #include <tuple>, sekcja zmienia swój rozmiar z 0x148a8 na aż 0x1d57f (jakies 36kB)

    Udało mi się również znaleźć podobny temat:

    https://community.arm.com/developer/tools-sof...2wulcRXEP7trMbVWLfV8Cvf5uGcH0FKKgWTqq14OZMbaE

    Czy u siebie wymuszasz jakiś konkretny format debugowania ? (np -gdwarf-3)

    Dodano po 28 [minuty]:

    Wygląda na to iż problem faktycznie związany był z .debug_info

    Jak wyczytać można w dokumentacji do DS-5:

    The DWARF 2 and DWARF 3 standard is ambiguous in some areas such as debug frame data. This means that there is no guarantee that the debugger can consume the DWARF produced by all third-party tools.

    Czyli, jeżeli kompilator wygeneruje kod w formacie DWARF 2, istnieje niezerowe prawdopodobieństwo, że coś nie zadziała.

    Można to sprawdzić poprzez readelf:

    arm-none-eabi-readelf --debug-dump executable.elf | grep -A 2 'Compilation Unit @'

    U mnie z tego co widzę, kompilator zależnie od jednostki kompilacji generuje informacje w wersji 2 lub 4 (czyli jak domniemuje DWARF 2 lub DWARF 4).

    I tu z pomocą przychodzi nam flaga -gstrict-dwarf.

    Jako rzecze dokumentacja do gcc:

    Disallow using extensions of later DWARF standard version than selected with -gdwarf-version. On most targets using non-conflicting DWARF extensions from later standard versions is allowed.

    Wstępnie problem rozwiązany, muszę jeszcze sprawdzić czy dla innym przypadków jest to samo :)
  • Specjalista - Mikrokontrolery
    en2 napisał:
    Czy u siebie wymuszasz jakiś konkretny format debugowania ? (np -gdwarf-3)

    Mam `-g -ggdb3` w flagach kompilacji i linkowania.
  • Poziom 5  
    U mnie jak dam -gddb3 to zaczyna niepokojąco wariować (np step in do funkcji foo1() powoduje chwilowe wejście do foo2(), by po jednym stepie przeskoczyć na odpowiednie miejsce).

    Miał ktoś podobnie ?

    @Freddie Chopin Czy jest jakaś ewolucja aby debugować Cortex-A przez VSCode (Jest jakaś wtyczka ale podobno do M)? Teraz niestety cały system pisania i budowania mam na wirtualce + ubuntu + gcc + vscode jednak debugować muszę nadal na DS-5.
  • Specjalista - Mikrokontrolery
    en2 napisał:
    U mnie jak dam -gddb3 to zaczyna niepokojąco wariować (np step in do funkcji foo1() powoduje chwilowe wejście do foo2(), by po jednym stepie przeskoczyć na odpowiednie miejsce).

    Miał ktoś podobnie ?

    Przy włączonej optymalizacji to zasadniczo (niestety) "normalne", ale przy -O0 nie powinno się tak dziać.

    en2 napisał:
    @Freddie Chopin Czy jest jakaś ewolucja aby debugować Cortex-A przez VSCode (Jest jakaś wtyczka ale podobno do M)? Teraz niestety cały system pisania i budowania mam na wirtualce + ubuntu + gcc + vscode jednak debugować muszę nadal na DS-5.

    Pewnie można wprost przez GDB i standardowy debugger? Albo może przy użyciu tej samej wtyczki co do Cortex-M ("cortex-debug" się chyba zwie). Generalnie ta wtyczka daje tylko lekką integrację z OpenOCD (lub innymi podobnymi programami) oraz opcję podlągu rejestrów peryferyjnych i rejestrów rdzenia. Jeśli Ci to nie potrzebne, to z pewnością na czystym GDB też się da debuggować zasadniczą aplikację.