Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugging not working with SPL examples #44

Open
maxgerhardt opened this issue Mar 23, 2021 · 8 comments
Open

Debugging not working with SPL examples #44

maxgerhardt opened this issue Mar 23, 2021 · 8 comments

Comments

@maxgerhardt
Copy link
Contributor

maxgerhardt commented Mar 23, 2021

Since I finally got an SPL example to build and upload correctly on my STM8S103F3 board per #43, I tried to access debugging, but it fails in the sense that it doesn't halt at the main function.

Reading symbols from C:\Users\Max\Documents\PlatformIO\Projects\stm8_init_proj\.pio\build\stm8sblue_stm8s103f3\firmware.elf...
Dwarf Error: Could not find abbrev number 117 in CU at offset 0x0 [in module C:\Users\Max\Documents\PlatformIO\Projects\stm8_init_proj\.pio\build\stm8sblue_stm8s103f3\firmware.elf]
(no debugging symbols found)...done.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

Info : tcl server disabled

It seems like there are no DWARF symbols available again although --debug --out-fmt-elf is given. Maybe GDB aborts loading DWARF information because of this error:

Dwarf Error: Could not find abbrev number 117 in CU at offset 0x0 [in module C:\Users\Max\Documents\PlatformIO\Projects\stm8_init_proj.pio\build\stm8sblue_stm8s103f3\firmware.elf]

Building with build_type = debug and feeding it directly into STM8-GDB

> C:\Users\Max\.platformio\packages\tool-stm8binutils\bin\stm8-gdb.exe .\.pio\build\stm8sblue_stm8s103f3\firmware.elf
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=stm8-none-elf32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .\.pio\build\stm8sblue_stm8s103f3\firmware.elf...Dwarf Error: Could not find abbrev number 117 in CU at offset 0x0 [in module C:\Users\Max\Documents\PlatformIO\Projects\stm8_init_proj\.pio\build\stm8sblue_stm8s103f3\firmware.elf]
(no debugging symbols found)...done.
(gdb) 

Gives the same error.

I'll investigate with a nother toolchain version, seems like SDCC is doing something weird here..

EDIT1: This is independent of the activated SPL modules btw, I've tested it with the old config and it fails in the same way.

@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented Mar 23, 2021

Per https://sourceware.org/legacy-ml/gdb/2002-08/msg00207.html I've run the file through readelf -wi and it also complains with the same errors. Debug information in the ELF seems to be incomplete somehow.. from some SPL modules..

 <1><2521>: Abbrev Number: 3 (DW_TAG_subprogram)
    <2522>   DW_AT_sibling     : <0x2630>
    <2526>   DW_AT_name        : I2C_Init
    <252f>   DW_AT_low_pc      : 0xa3e1
    <2533>   DW_AT_high_pc     : 0xa5b4
    <2537>   DW_AT_external    : 1
    <2538>   DW_AT_frame_base  : 0x4114 (location list)
[..]
 <2><2590>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <2591>   DW_AT_location    : 2 byte block: 91 a     (DW_OP_fbreg: 10)
    <2594>   DW_AT_name        : AddMode
    <259c>   DW_AT_type        : <0x2651>readelf: Warning: Unable to find entry for abbreviation 117

 <2><25a0>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <25a1>   DW_AT_location    : 2 byte block: 91 b     (DW_OP_fbreg: 11)
    <25a4>   DW_AT_name        : InputClockFrequencyMHz
    <25bb>   DW_AT_type        : <0x2651>readelf: Warning: Unable to find entry for abbreviation 117

@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented Mar 23, 2021

Full readelf -wi output with a minimal firmware (all modules but GPIO disabled) shows some errors even within the GPIO module for functions / structures that however used in the SPL code..

https://pastebin.com/tz2Sjver

@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented Mar 23, 2021

I've filed a bug at SDCC per https://sourceforge.net/p/sdcc/bugs/3200/ since I don't see where out fault could be (in e.g. the invocation or linking phase).

Sadly we're depending on two SDCC bugs (this plus #38 (comment)) to get a good debugging experience with non-baremetal projects.

@valeros
Copy link
Member

valeros commented Mar 23, 2021

Thanks for looking into the problem. There was also an update for stm8-binutils a year ago or so, but I'm not sure it has something to do with this issue.

@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented Mar 23, 2021

If the standard readelf bintools of my latest MinGW installation and stm8-gdb throw this error with Bogus end-of-siblings marker and Unable to find entry for abbreviation for the generated ELF file, I'm more suspecting it has something to do with SDCC, but I hope we'll find out the cause soon.

@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented May 11, 2021

There have been new developments regarding this in error in here -- it seems that the linking order of the .rel files is the main culprit for the DWARF error occurring. The .rel file in which the main() function occurrs must come first. Not sure about the order of the other files. But with a workaround to influence the linking order (that is, for the spl-blinky project, move the stm8s_gpio.c file from the framework to the project itself to force a main.rel stm8s_gpio.rel linking order), debugging was shown to be possible.

I must yet reproduce this on my own but it looks very promising. Maybe @valeros can have a look at this too.

@maxgerhardt
Copy link
Contributor Author

There have been new developments in this with the SDCC devs saying this bug is fixed.

The "Bogus end-of-siblings marker detected..." problems should be fixed in [r12536]

Have to get around to testing it. If it works now, it would finally enable full debugging..

@stefaandesmet2003
Copy link

Not sure if this helps, but in my setup debugging STM8 with SPL framework seems working.
I'm on Ubuntu 20.04, so I don't have the windows related SDCC issues.
I don't have "Warning: Unable to find entry for abbreviation ..." errors from readelf -wi, but I do see the "Bogus end-of-siblings marker detected...", so I assume for my setup they are harmless.

platformio.ini is :

[env:stm8sblack]
platform = ststm8
board = stm8sblack
framework = spl
upload_protocol = stlinkv2
debug_tool = stlink

The test code is a simple blinky.

Screenshot from 2021-08-24 15-29-11
pio project content:
Screenshot from 2021-08-24 15-36-28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants