English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. C/C++ (http://eab.abime.net/forumdisplay.php?f=118)
-   -   m68k-amigaos-gdb (http://eab.abime.net/showthread.php?t=93055)

bebbo 18 November 2019 08:58

Quote:

Originally Posted by Tom_Goblins (Post 1359692)
I am using Bebbo's GCC using c++ and it works great for me (Thanks Bebbo! :)).


Woot! Someone is using it ;)





Quote:

Originally Posted by Tom_Goblins (Post 1359692)
...

but as an Amiga program when I disable system, the server running on the amiga goes away too (maybe I am missing something here?).
...


Since bgdbserver uses a TCP connection Forbid() will kill this too.


But Forbid() usage should be rare - maybe you could use a semaphore instead?

Tom_Goblins 19 November 2019 01:29

Thanks for the reply Bebbo.

I will need to double check, I am not using forbid() specifically that I know. I use some startup code from loonies, my guess is that is disabling interrupts and dma to kill the system, that disables the gdbserver, I will check that.

I saw that those integrations on *UAE with gdb and sounds great but they "hate" c++ or I dont know how to make it work.

some questions for you then?

Would be possible to adapt your gdbserver to be part of a modified version of FS-UAE or WinUAE so it could be at the emulator level?

Have you tried connecting from VSCode using the GDB, I think I got it working once, but not sure if it is meant to work with it.

Not sure if I am crazy, trying to do my stuff in modern c++, as I can see most of people just avoid it in favor of plain C XD?

bebbo 19 November 2019 09:53

Quote:

Originally Posted by Tom_Goblins (Post 1359924)
Thanks for the reply Bebbo.

I will need to double check, I am not using forbid() specifically that I know. I use some startup code from loonies, my guess is that is disabling interrupts and dma to kill the system, that disables the gdbserver, I will check that.

I saw that those integrations on *UAE with gdb and sounds great but they "hate" c++ or I dont know how to make it work.

some questions for you then?

Would be possible to adapt your gdbserver to be part of a modified version of FS-UAE or WinUAE so it could be at the emulator level?

Have you tried connecting from VSCode using the GDB, I think I got it working once, but not sure if it is meant to work with it.

Not sure if I am crazy, trying to do my stuff in modern c++, as I can see most of people just avoid it in favor of plain C XD?


Q1: I guess there is a WinUAE version containing a gdb server. I have no clue if my code would be helpful there.



Q2: I never tried it. I'm using Eclipse - it's working despite it needs a hack for the Amiga.


I'm using the libnix library if I code something for the Amiga also with c++. You can create programs with a reasonable size even using c++. But it's easy to blow the code size up^^



Plus I also debug my real Amiga over TCP.

Tom_Goblins 19 November 2019 18:02

I am happy with the current setup on c++ but I am missing a good way to debug. I just go around with old school debugging but it is not great. :)

Code size goes nuts as you use c++ libs, so I have pretty minimal usage of them, to keep executable size manageable. For debugging I can get a 800K exe :).

I will keep advancing my project with c++ but I can always fall back to plain C if I find some obstacles moving forward.

bebbo 20 November 2019 09:35

Quote:

Originally Posted by Tom_Goblins (Post 1360032)
Code size goes nuts as you use c++ libs, so I have pretty minimal usage of them, to keep executable size manageable. For debugging I can get a 800K exe :).


for 'smaller' c++:


- don't use std::streams
- use -fno-exceptions -fno-rtti - unless you are really using excpetions/rtti
- use -flto
- move non-inlineable member functions into a corresponding cpp file
- use base classes - even for templates - with common code in cpp files
- don't use codesize increasing c++ features because these exist or you think it's cool... - but use these if it's a real benefit

Toni Wilen 20 November 2019 19:01

Quote:

Originally Posted by Tom_Goblins (Post 1359924)
Would be possible to adapt your gdbserver to be part of a modified version of FS-UAE or WinUAE so it could be at the emulator level?

I was originally against doing this because I don't really like GDB (for example disassembly syntax is simply horrible..) but now that there are better options than basic GDB so perhaps this is good idea after all..

Tom_Goblins 20 November 2019 20:47

Quote:

Originally Posted by bebbo (Post 1360141)
for 'smaller' c++:


- don't use std::streams
- use -fno-exceptions -fno-rtti - unless you are really using excpetions/rtti
- use -flto
- move non-inlineable member functions into a corresponding cpp file
- use base classes - even for templates - with common code in cpp files
- don't use codesize increasing c++ features because these exist or you think it's cool... - but use these if it's a real benefit


Thanks for the tips, basically I am using some of them, my debug exe is huge, but release is under 50K, which I can do better but good enough to keep going. :)

I use c++ but close to simple C to avoid that library explosion. but as today, I don't see much benefits on doing the project on plain C. C++ has a bad reputation, in part I think for people getting lost on complex and obscure language constructions. But c++ can be as plain and simple as C in IMHO.

Tom_Goblins 20 November 2019 20:55

Quote:

Originally Posted by Toni Wilen (Post 1360249)
I was originally against doing this because I don't really like GDB (for example disassembly syntax is simply horrible..) but now that there are better options than basic GDB so perhaps this is good idea after all..

I am not a great fan of GDB myself either, but after seeing some of these integrations on VSCode and other debuggers. I think having that integrated at the emulator level is awesome.

That being said, I want to thank you a lot for your work on WinUAE. It is probably the one big reason why I came back to Amiga and me and my group we are still doing productions for it. I have also a Mist (FPGA) but I use WinUAE all the time.

jotd 20 November 2019 21:33

A gdb server integrated in WinUAE would be awesome! My C++ game is OS friendly to a point so I don't care.

But it also opens new perspectives: for instance I think that a WinUAE-based server could catch illegal instructions, misaligned addresses, illegal writes, …, or some GURUs, allowing to see the stacktrace of the faulty code. Today, the whole thing goes guru.

Also watchpoints would be possible at source level (since WinUAE asm debugger already has watchpoints). But we're probably talking of too much work.

JuanLuis 29 January 2020 22:35

I'm trying to use m68k-amigaos-gdb from CygWin64 with a program executed on WinUAE with m68k-amigaos-gdb running in a CygWin64 console. I was able to connect with gdb with the process running on emulated Amiga by remote debugging but gdb says that symbols are not found.

There is a suspicious thing. Despite the program is compiled with -g option the size of executable is similar to Release executable compiled without -g option, so I suspect that symbolic information is not included in Amiga executable.

Which are the options do you use to compile and debug?
What am I doing wrong?

Thanks in advance.

jotd 29 January 2020 22:52

Got caught by this. You have to LINK with -g too. Check your .o sizes. They should be bigger.

JuanLuis 30 January 2020 15:59

Quote:

Originally Posted by jotd (Post 1375225)
Got caught by this. You have to LINK with -g too. Check your .o sizes. They should be bigger.

Yes, it works. The file is bigger and I can connect with gdb, but I have to load symbol file from Amiga executable on my PC directory. I expected that symbols were loaded from Amiga.

I have set breakpoints on several lines but I were unsuccessful stopping and evaluating variable values, but perhaps I'm doing things wrongly with gdb. I have to investigate gdb options.

jotd 30 January 2020 17:55

The symbols are loaded from both sides actually. gdb server from amiga side needs them IIRC.

evaluating sometimes doesn't work on some variables... But breakpoints work.

JuanLuis 30 January 2020 19:29

2 Attachment(s)
Quote:

Originally Posted by jotd (Post 1375388)
The symbols are loaded from both sides actually. gdb server from amiga side needs them IIRC.

evaluating sometimes doesn't work on some variables... But breakpoints work.

Not in my case. Compiling messages are:
Code:

cd 'C:\Users\Juan Luis\Documents\NetBeansProjects\ArgsTest'
D:\cygwin64\bin\make.exe -f Makefile CONF=Debug clean
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: se entra en el directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
rm -f -r build/Debug
make[1]: se sale del directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'

CLEAN SUCCESSFUL (total time: 1s)
cd 'C:\Users\Juan Luis\Documents\NetBeansProjects\ArgsTest'
D:\cygwin64\bin\make.exe -f Makefile CONF=Debug
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: se entra en el directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
"/usr/bin/make"  -f nbproject/Makefile-Debug.mk dist/Debug/Amiga_Cygwin64_Bebbo2-Windows/argstest.exe
make[2]: se entra en el directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
mkdir -p build/Debug/Amiga_Cygwin64_Bebbo2-Windows
rm -f "build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o.d"
m68k-amigaos-g++ -noixemul  -c -g -std=c++14 -MMD -MP -MF "build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o.d" -o build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o main.cpp
mkdir -p dist/Debug/Amiga_Cygwin64_Bebbo2-Windows
m68k-amigaos-c++.exe -o dist/Debug/Amiga_Cygwin64_Bebbo2-Windows/argstest build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o  -g
make[2]: se sale del directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
make[1]: se sale del directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'

BUILD SUCCESSFUL (total time: 2s)


I can't list source code on gdb when I try to debug from my PC. I attach compiling output and how I try to debug from my CygWin terminal running on my Windows. Please, tell me if I'm doing something wrong.

jotd, thanks in advance.

jotd 30 January 2020 19:32

Everything is fine on the amiga side, but on the windows side, you have to use "file amiga-executable" on the Windows side, so the symbols are loaded into the debugger client side (before using "target" command). After that it should work.

JuanLuis 01 February 2020 21:25

2 Attachment(s)
Quote:

Originally Posted by jotd (Post 1375406)
Everything is fine on the amiga side, but on the windows side, you have to use "file amiga-executable" on the Windows side, so the symbols are loaded into the debugger client side (before using "target" command). After that it should work.

jotd, I have loaded symbol-file as you can see in my attached picture. I was able to list source code. After this, I set a breakpoint on line 4. I tried to run the program with gdb "run" command, but gdb console rejected it telling:

The "remote" target does not support "run". Try "help target" or "continue".

I tried step command without success. Finally, I entered "continue" gdb command, but Amiga bgdbserver run the program without stopping on breakpoint. GDB client says that GDB server killed the program.

One suspicious thing is the arguments shown by the program are not the provided arguments in command line (see the first line on Amiga Console). I have already discussed that on other thread of EAB forum with Bebbo. Bebbo told me that the cause of this problem was I wasn't using -noixemul option when compiling. However, when I link with -g option this problem appears again.

Do you think that the program is compiled properly?

Am I doing something different compared with your way of debugging?

pipper 01 February 2020 21:43

As a sidenote: you don’t need the exe with debug symbols on the target machine. Instead, one can use a stripped version on the Amiga. Only the host debugger (gdb) needs the executables with symbols.

jotd 01 February 2020 22:28

don 't use "run", use "continue" (or c).

run is only for native programs.

that said, same thing happens to me now. I could debug my program for a while, then I probably changed things in the code, and running with debug now is not possible with the current version of my game (but my game works, and I can manage without debug fortunately). Maybe try with a super-simple program to start with.

JuanLuis 04 February 2020 01:48

Quote:

Originally Posted by jotd (Post 1375823)
don 't use "run", use "continue" (or c).

run is only for native programs.

that said, same thing happens to me now. I could debug my program for a while, then I probably changed things in the code, and running with debug now is not possible with the current version of my game (but my game works, and I can manage without debug fortunately). Maybe try with a super-simple program to start with.

Yes, but I couldn't debug my program. As you can see on attached images my program is executed until the end. I'm a little bit frustrated because I wasn't even able to stop the execution in a breakpoint.

It's very hard to debug a large program without debugging support. I expected this was easier, but I don't know what I'm doing wrong.

My program is super-simple. The program I intend to debug is this:

Code:

#include <stdio.h>

int main(int argc, char** argv) {
    for (int i = 0; i < argc; i++)
        printf("Arg #%d -> \"%s\"\n", i, argv[i]);
               
    return 0;
}

I tried to set a break point on for loop, but the program doesn't stop on it.

bebbo 04 February 2020 11:49

Quote:

Originally Posted by JuanLuis (Post 1376387)
...


It's very hard to debug a large program without debugging support. I expected this was easier, but I don't know what I'm doing wrong.


...


learn gdb - first lesson: how to set a break point.
watch closely:
Code:

stefan@ZETRA:~/amiga-gcc/tickets/eab7$ m68k-amigaos-g++ -g test7.c -o test7
stefan@ZETRA:~/amiga-gcc/tickets/eab7$ m68k-amigaos-strip test7 -o /mnt/c/Amiga/MyWB31/Develop/prj/test/test7



WINUAE: bgdbserver test7



stefan@ZETRA:~/amiga-gcc/tickets/eab7$ m68k-amigaos-gdb test7
GNU gdb (GDB) 8.3.50.200102-195310-git
Copyright (C) 2019 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-pc-linux-gnu --target=m68k-amigaos".
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 test7...
(gdb) target remote :2345
Remote debugging using :2345
warning: Target reported unsupported offsets: Text=4062b0e0;Data=4059fb50;Bss=4059ff68
0x4062b0e0 in _stext ()
(gdb) list
1      #include <stdio.h>
2
3      int main(int argc, char** argv) {
4          for (int i = 0; i < argc; i++)
5              printf("Arg #%d -> \"%s\"\n", i, argv[i]);
6                     
7          return 0;
8      }
9
(gdb) b main:4
Breakpoint 1 at 0x4062b316: file test7.c, line 4.
(gdb) c
Continuing.

Breakpoint 1, main (argc=1, argv=0x4059ff68) at test7.c:4
4          for (int i = 0; i < argc; i++)
(gdb) c
Continuing.

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb)


so use
b main:4
instead of
b 4


All times are GMT +2. The time now is 11:26.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.

Page generated in 0.07917 seconds with 11 queries