ESP32 Forum

Posted: **Tue Aug 06, 2024 10:22 am**

CC = xtensa-lx106-elf-gcc
CFLAGS = -I. -DICACHE_FLASH -mlongcalls -Og
LDLIBS = -nostdlib -Wl,--start-group -lmain -lnet80211 -lwpa -llwip -lpp -lphy -lc -Wl,--end-group -lgcc
LDFLAGS = -Teagle.app.v6.ld -ggdb
INCLUDES = -Iinclude -I../driver_lib/include

SUBDIRS = gdbstub
COMPONENTS_eagle.app.v6 = gdbstub/libgdbstub.a

fotaMain-0x81000.bin: LDFLAGS=-Teagle.app.v6.new.2048.ld  -ggdb
fotaMain-0x81000.bin: Main
esptool.py write_flash --flash_size 32m-c1 0x101000 Main-0x01000.bin

fotaMain-0x01000.bin: LDFLAGS=-Teagle.app.v6.new.2048.ld -ggdb
fotaMain-0x01000.bin: Main
	echo c
	echo $(LDFLAGS)
	esptool.py elf2image --version 2 Main   
	esptool.py write_flash --flash_size 32m-c1 0 ../library/boot_v1.7.bin 0x1000 Main-0x01000.bin 0x3FB000 ../library/blank.bin 0x3FE000 ../library/blank.bin 0x3FC000 ../library/esp_init_data_default_v08.bin 0x64000 ../library/index.html 0x66000 ../library/config.html
	
	Main: Main.o $(SUBDIRS)/gdbstub.o $(SUBDIRS)/gdbstub-entry.s

Main.o: Main.c

$(SUBDIRS)/gdbstub.o: $(SUBDIRS)/gdbstub.c
	$(CC) $(CFLAGS) -c $< -o $@

$(SUBDIRS)/gdbstub-entry.o: $(SUBDIRS)/gdbstub-entry.s

Hi everyone, I was working on my previous post as to preserving the stacktrace for the esp8266 with no luck, so I decided to try to implement gdbstub as it comes with that functionality.

I am currently running 3.0.2 NONOS-SDK (Yes I am aware this is not under full support anymore) and am leveraging the esp-open-sdk
https://github.com/pfalcon/esp-open-sdk

I then downloaded the source files and placed them within my project folder as directed: https://github.com/espressif/esp-gdbstub

Updated my make file above, totally unsure if its correct but did the best I could to get it to fly and then I got stuck on compiling the .s ASM code.. It is currently returning that rsr cant be applied to the DEBUG_PS micro. I can only assume it has something to do with how my gcc compiler is interpreting the .S but any pointers in the right direction would be greatly appreciated!!

If anyone has more of a stand alone solution to preserve the stack trace that would also partly resolve my issue but being able to breakpoint and to get gdbstub to work with my nonos sdk would be a pie in the sky as well!

Posted: **Wed Aug 07, 2024 3:44 am**

Potentially you're missing an include that defines those symbols to whatever the Xtensa assembler wants. Sorry, I don't know what include that would be, it's been ages since I touched an 8266.

Posted: **Wed Aug 07, 2024 4:25 am**

ESP_Sprite wrote: ↑
Wed Aug 07, 2024 3:44 am
Potentially you're missing an include that defines those symbols to whatever the Xtensa assembler wants. Sorry, I don't know what include that would be, it's been ages since I touched an 8266.

That is really odd, I fell like I've followed the instructions to a 'T' and have read them multiple multiple times.

Is it your understanding this is due to a missing .H file that would be added to the blinky.c file for example and not a ".a"(Library file) ?

Posted: **Wed Aug 07, 2024 5:54 am**

AgentSmithers wrote: ↑
Wed Aug 07, 2024 4:25 am
Is it your understanding this is due to a missing .H file that would be added to the blinky.c file for example and not a ".a"(Library file) ?

No, you'd need to #include it in the assembly file that throws those errors.

Posted: **Wed Aug 07, 2024 8:50 am**

ESP_Sprite wrote: ↑
Wed Aug 07, 2024 5:54 am

AgentSmithers wrote: ↑
Wed Aug 07, 2024 4:25 am
Is it your understanding this is due to a missing .H file that would be added to the blinky.c file for example and not a ".a"(Library file) ?
No, you'd need to #include it in the assembly file that throws those errors.

Thanks, Ive spent a few hours trying to diag the issue. Im going to dive a bit more into it tomorrow and see if I can gain any traction. I wonder if it has something to do with my make file at all but Ill investigate the headers in the .S file meanwhile.

Doing some additional reading, are the registered defined in the eagle.app.v6.ld by any chance? I am currently using the LDFLAGS=-Teagle.app.v6.new.2048.ld for compiling my firmware. I'm wondering if there's something up with the defines in that file....

So I am currently using the esp-open-sdk, and specreg.h seems to have different amount of declares then the RTOS version
Mine matches this: https://github.com/tommie/lx106-hal/blo ... /specreg.h

However, after reviewing the RTOS version here: https://github.com/espressif/ESP31_RTOS ... /specreg.h

There is a clear difference. I am unsure if that is also apart of the issue.

ESP32 Forum

Compiling .S using xtensa-lx106-elf-gcc

Compiling .S using xtensa-lx106-elf-gcc

Re: Compiling .S using xtensa-lx106-elf-gcc

Re: Compiling .S using xtensa-lx106-elf-gcc

Re: Compiling .S using xtensa-lx106-elf-gcc

Re: Compiling .S using xtensa-lx106-elf-gcc