FYI: Posting screen shots is close to useless.
It is usually some important prerequisite missing. I just ran compilation of the whole thing on ubuntu 22.10 without any issues. https://sourceware.org/gdb/onlinedocs/gdb/Requirements.html
Did you do as described in the README file? Also check for any errors from configure script.
What I meant was to compile in linux under wsl for linux instead of cygwin. In any case building under cygwin should be no problem either. /Ake
Or compile it under WSL is perhaps better.
Instructions here: https://stm8-binutils-gdb.sourceforge.io/ Find the requirements for building here: https://sourceware.org/gdb/current/onlinedocs/gdb/Requirements.html And in addition if you want TUI mode you should also install ncurses libraries.
Precompiled cygwin binaries are no longer provided. You need to compile it your self... /Ake
Running stm8-gdb under python 3.8 generates warnings
Hello, you are probably experiencing the python insanity of breaking old code. Try running with python 2 instead or if you don't need python configure gdb with "--with-python=no"
Hello, you are probably experiencing the python insanity of breaking old code. Try compiling with python 2 instead or if you don't need python configure gdb with "--with-python=no"
stm8-binutils-gdb-20210718 release
Thanks for your effort. Have you tested this patch with older versions of python as well?
Ok, I don't think make should fail though.... /Ake On 2020-07-23 17:45, Maxim wrote: Yes, the problem was resolved (there was no a problem actually). I considered that the log of make I posted above is an error, but it's actually not. compilation on ubuntu https://sourceforge.net/p/stm8-binutils-gdb/discussion/general/thread/6018d64570/?limit=25#8547/cd98/7c7d Sent from sourceforge.net because ake.rehnman@gmail.com is subscribed to https://sourceforge.net/p/stm8-binutils-gdb/discussion/general/ To...
Was the problem resolved and what was the issue?
flash/nor/nrf5: pass unsigned char to isalnum()
stlink: remove only instance of useconds_t
stm8 target: make adapter speed settings work
Entering SWIM mode on ST-LINK does not update swim status word.
Entering SWIM mode on ST-LINK does not update swim status word.
Entering SWIM mode on ST-LINK does not update swim status word.
stm8-binutils-gdb-20200322 release
Options in usage example
Missing link to tracker on website
Include stm8 while building multi architecture gdb
Merged
Missing bccm opcodes, incorrect cplw mnemonic
Patch is merged
Hello and thanks for your interest in the stm8-binutils project. Unfortunately there are no plans for supplying packages for macOS. In fact I am planning on removing the packages for cygwin as well.
Thanks for your contribution. I will work this patch into the next revision. /Ake
STM8 Target relicensing to GPLv2 and later
STM8 Target relicensing to GPLv2 and later
FYI I just recompiled everyting with gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 without any problems.
I am out of ideas. You must have something funky going on with your build environment. Could you post the command line for the failing ser-tcp.c source e.i "g++ .... ser-tcp.c" ?
Just compiled everything in ubutu gcc 5.4.0 without any problems. I am not sure why compilation fails for you. Looking in /usr/include/unistd.h: #if defined __USE_MISC || defined __USE_XOPEN # ifndef __socklen_t_defined typedef __socklen_t socklen_t; # define __socklen_t_defined # endif #endif and __USE_MISC is defined in /usr/include/features.h: #if defined _DEFAULT_SOURCE # define __USE_MISC 1 #endif The `-ansi' switch to the GNU C compiler, and standards conformance options such as `-std=c99',...
Stupid question but did you "make distclean" after changing compiler?
Have you seen this? https://stackoverflow.com/questions/52451352/why-gdb8-2-compile-error-on-centos7-aliyun
What is the rest of the error message saying?
Hello, you are probably missing some libraries like ncurses to make tui work. Check your config.log. Regarding missing symbols, make sure you have --debug option enabled when compiling. BR /Ake
Btw, I suggest you try SDCC just to get a feel how it works the way it should. SDCC is not perfect when it comes to debugging, specifically it has some trouble tracking where the variables are at.
The way "next" works in gdb is it always do single step and after each step it checks if the stack frame was changed. If it was it use the debug info to figure out where on the stack (or in what register for processors with a return register) the return address is located. Then it insert a breakpoint at the return address and issue a countinue. I am not sure why it looks for reg 4, if it is the same reg 4 as in the stm8 port of gdb it is the stackpointer. Remember the way DWARF stack unwinding works...
Hi Valentin, my personal opinion regarding eclipse it is terrible for debugging. Don't get me wrong eclipse is great in many ways but it never worked well for any micros I tried. That said, you would have to look at openocd with debug messages on to try figure out why it hangs. Regarding your troubles with stepping over, it is probably a matter of inadequate debugging info. Gdb it self (and my port) is unable to do stack unwinding, it relies 100% on the DWARF debug info where to find the return address...
Hi Martin, I don't get a whole lot of feedback for the stm8 binutils project. So from that one could draw two conclusions, either it is working fabulously good or no body is using it... I do have a few minor changes that should committed all of them related to PTR index register instructions being wrongly relocated in the stm8 assembler. If you have any other suggestions or ideas I am eager to hear them. BR /Ake
Now I am not sure if there are similar multi-architecture options for the other binutil tools as nm ld objdump etc etc. All i know is there is a --enable-targets=all when building binutils but I have never tested if it works or if the make files needs some attention. /Ake On 2018-11-06 12:24, Antonio Borneo wrote: What do you mean for "make a patch for the whole binutils package"?
Yes, please make a patch for the whole binutils package if you have time.
Thank you. I will include this patch in the next release.
That is download the OpenOCD sources from the OpenOCD git repository https://sourceforge.net/p/openocd/code/ci/master/tree/ Notice how ever the "Download Snapshot" method will not work (last time it tested) since the repo contains sub repositories. Only "git clone" will work...
Hello Logan, you are correct the SDCC now produce enough dwarf debugging info to be able to debug the code. The patches for OpenOCD was also merged upstream. However the new OpenOCD is not released yet so you would have to to download the OpenOCD sources and build it your self to get STM8 debugging.
Hi, you are absolutely right it is a big trouble to get eclipse to co-work with gdb especially all these path troubles. I don't know if compiling gdb for mingw would make it better. As for your specific troubles with target not responding, it could be a number of problems ranging from eclipse is wrongly configured or openocd is not responding. In any case you should try launching gdb from command line with tui or cli interface and check everything works as expected. When you have verified everything...
Faulty CC register size
Fixed in release 2018-03-04
stm8-binutils-gdb-20180304 release
bug in regession test bug2783061
compiler crash when doing long multiplications
stm8: fix compilation warning
Seems the symbols does not have any block numbers attached. This is what is in symbol given to dwWriteSymbol. Block is always 0... $1 = {name = "y", '\000' <repeats 63 times>, rname = "_test2_y_1_2", '\000' <repeats 180 times>, level = 1, block = 0, seqPoint = 4, key = 2, flexArrayLength = 0, implicit = 0, undefined = 0, infertype = 0, _isparm = 0, ismyparm = 0, isitmp = 0, islbl = 0, isref = 1, isind = 0, isinvariant = 0, cdef = 0, addrtaken = 0, isreqv = 0, udChked = 0, generated = 0, isinscope...
dwarf debugging: local variables has wrong scope
stlink_usb: Changes to make connect_under_reset work
stlink_usb: Changes to make connect_under_reset work
stlink_usb : Resolved a collision with JTAG API v1
Added config files for stm8l152 stm8s003 and stm8s105
stlink_usb: Changes to make connect_under_reset work
stlink_usb : Resolved a collision with JTAG API v1 and
jtag/drivers/stlink_usb : implemented and repaired SWIM support
Hello and thanks for your interest in the stm8 binutils project. Nothing terrible will happen if you install the stm8-binutils in parallel with your avr tools. The stm8-binutils tools will be prefixed with stm8- and so it will not clash. The latest release for sdcc is 3.6.0 as far as I know. If you pulled the source from the repository (trunk) there is support for DWARF debugging already in there. How ever it is not compatible with the released version of the stm8-binutils tools. I plan to relase...
Hello and thanks for your interest in the stm8 gdb project. It is usually a reset problem. Or the swim port pin is reconfigured during early startup code. Difficult to say, you should provide a debug dump with -d3 flag. You might also try editing stm8.cfg and enable connect under reset (look at the end of the stm8.cfg). Or use soft reset by changing reset config to none with 'reset_config none'.
stm8 : new target
Added config files for stm8l152 stm8s003 and stm8s105
stlink_usb: Changes to make connect_under_reset work
stm8 : new target
stlink_usb: Changes to make connect_under_reset work
Added config files for stm8l152 stm8s003 and stm8s105
stlink_usb: Changes to make connect_under_reset work
stlink_usb: Changes to make connect_under_reset work
stm8 : new target
Added config files for stm8l152 stm8s003 and stm8s105
jtag/drivers/stlink_usb : implemented and repaired SWIM support
stm8 : new target
Bug in stm8_write_flash preventing flashing of small blocks
stm8 : new target
Changed stm8_reset_deassert to wait for TARGET_HALTED
Added config files for stm8l152 stm8s003 and stm8s105
Added enable_stm8l option
Changes to make connect_under_reset work
jtag/drivers/stlink_usb : implemented and repaired SWIM support
Hello Michael, thanks for your interest in the stm8-gdb project. I'm working actively to improve the debuging information in sdcc. It already have dwarf debugging tables but it needs some work. I hope it will be ready for the next sdcc release. For openocd I made an effort to get the new stm8 target comitted. It did get some attention in the beginning. How ever after I submitted the code for review a few times it was downvoted because of "unpretty coding". Basically it didn't matter what I did, after...
New patch uploaded. Based on r10063. The previous patch file was containing all the patches I've made unforunately. I hope I didn't confuse things too much. It's just one file affected by this patch, lkelf.c /Ake
Done. SDCC changes submitted upstream.
Soft framepointer vs. CFS without framepointer
STM8: Add stack initialization in gs_init
ELF e_entry is missing for STM8
I have patched in the missing pieces to produce debug-line info for stm8 gen.c But we still need debug-frame info as well to be able to unwind the stack W/o a fp.
I have patched in the missing pieces to produce debug-line info for stm8 gen.c But we still need debug-frame info as well to be able to unwind the stack W/o a fp. On 8 Oct 2017 5:18 p.m., "Philipp Klaus Krause" spth@users.sf.net wrote: Erik fixed that issue a week ago. Are there further SDCC problems, that need to be sorted out before debugging can be done without a frame pointer? Philipp [tickets:#3] https://sourceforge.net/p/stm8-binutils-gdb/tickets/3/ Soft framepointer vs. CFS without framepointer*...
The version used is trunk@10031
hc08: compiling with -debug flag emit warnings
Actually since the last discussion we had I made an effort to fix the cfa debug info. However since the debug debug code generation for stm8/hc08 is somehow broken in the trunk and no response in the mailing list I gave up... https://sourceforge.net/p/sdcc/mailman/message/35836515/
Thanks for your good work, what about just call the stm8.cfg then on the next line add "reset_config none" ? #config script for STM8S001 #set ENABLE_STEP_IRQ 1 set FLASHEND 0x9FFF set BLOCKSIZE 0x40 proc stm8_reset_rop {} { mwb 0x4800 0x00 reset halt } source [find target/stm8.cfg] reset_config none
I have to revise my previous statement. It DOES work as excpected with my small test. I how ever discovered a couple of problems. 1) There is a bug in the startup code, the sp register is not initialized correctly. A freshly resetted system should work though. 2) If there is a function returning long long type makes gdb confused somehow showing argments wrongly. Single stepping machine instructions will show the above <error reading="" variable=""> during the prolouge. This is normal. Line stepping...
Hmm, I made a small test with a library and I get the same result. dummyx (x=<error reading variable: Could not find the frame base for "dummyx".>) at dummyx.c:8 dummyx (x=-60798456842731264) at dummyx.c:10