GNU GDB
-
- Font of All Knowledge
- Posts: 3971
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
GNU GDB
Hi,
I have been looking at GNU GDB - Debugger in Linux.
I hoped that compiling a C68 programme with the -g option to include debugging information, that GNU GDB would load the C68 executable.
But as expected GNU GDB does know about QDOS file types and does not load the C68 compiled executable.
Maybe a QL port of a earlier version of GNU GDB may be an idea, does anyone think this is a good idea...
I have been looking at GNU GDB - Debugger in Linux.
I hoped that compiling a C68 programme with the -g option to include debugging information, that GNU GDB would load the C68 executable.
But as expected GNU GDB does know about QDOS file types and does not load the C68 compiled executable.
Maybe a QL port of a earlier version of GNU GDB may be an idea, does anyone think this is a good idea...
Regards,
Derek
Derek
- NormanDunbar
- Forum Moderator
- Posts: 2276
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: GNU GDB
Hi Derek,
I'm not sure any version of Gnu gdb will work with a C68 compiled executable.
I have a vague recollection that Dave (Dave Walker) was at some point in the past, working on a debugger for C68 -- but maybe I made that up! Google says "no"!
Compiled code is a tad difficult to trace with QMON2, however, what I've been doing in the Free Pascal stuff (which I must get some time to get back to) is to build a TRAP #15 into the code, then ET the job in QDOSMSQ, find the job number (it would be nice if ET returned the job number!) and start QMON2 with that job.
I then enter the command TL 14 followed by G. That gets the executable running and it will trap into QMON2 when it hits the TRAP #15. The problem is, that's fine for when I'm tracing my assembly code or similar in the library routines I'm writing for FPC, it's not so good when trying to trace the Pascal code itself -- or C68 in this case.
So, yes, a C68 debugger would be a great idea. But, I doubt gdb will be suitable.
Happy to be proved wrong though,
Cheers,
Norm.
I'm not sure any version of Gnu gdb will work with a C68 compiled executable.
I have a vague recollection that Dave (Dave Walker) was at some point in the past, working on a debugger for C68 -- but maybe I made that up! Google says "no"!
Compiled code is a tad difficult to trace with QMON2, however, what I've been doing in the Free Pascal stuff (which I must get some time to get back to) is to build a TRAP #15 into the code, then ET the job in QDOSMSQ, find the job number (it would be nice if ET returned the job number!) and start QMON2 with that job.
I then enter the command TL 14 followed by G. That gets the executable running and it will trap into QMON2 when it hits the TRAP #15. The problem is, that's fine for when I'm tracing my assembly code or similar in the library routines I'm writing for FPC, it's not so good when trying to trace the Pascal code itself -- or C68 in this case.
So, yes, a C68 debugger would be a great idea. But, I doubt gdb will be suitable.
Happy to be proved wrong though,
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: GNU GDB
Maybe that's why the FET command was inventedNormanDunbar wrote:Compiled code is a tad difficult to trace with QMON2, however, what I've been doing in the Free Pascal stuff (which I must get some time to get back to) is to build a TRAP #15 into the code, then ET the job in QDOSMSQ, find the job number (it would be nice if ET returned the job number!) and start QMON2 with that job.
But I personally would just use "JMON win1_blah_exe".
I don't think there will ever be a good debugger solution for the QL, it's just too much work. TT started on SMON 25 years ago and had big plans, but alas it was never in a usable state. At best we can import a MAP file one day into one of the existing debuggers, not even dreaming of a source based approach.
Marcel
- NormanDunbar
- Forum Moderator
- Posts: 2276
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: GNU GDB
Oh come on Marcel, it took me years to find out what ET was for, other than calling home! You expect me to keep up with these things! (In other words, thanks!)mk79 wrote:Maybe that's why the FET command was invented
I used to always use JMON, but I remember having problems with it simply hanging up for no reason during a debugging session, so I started using QMON2 all the time. It might be something to do with me being on Linux under Wine when running QPC2, but I haven't checked it out for a while, I will probably do so now you reminded me.mk79 wrote:But I personally would just use "JMON win1_blah_exe".
If Tony couldn't create a working debugger, then what hopes for the rest of us mortals. Maybe yourself and Wolfgang could do it (!!!!!!!) but I suspect there's nobody else with a big enough brain. I certainly (probably) couldn't! Although, someone might want to prove that they can do it themselves -- wouldn't that be nice!
Regarding a source level debugger, well, we can but dream.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
-
- Font of All Knowledge
- Posts: 3971
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: GNU GDB
Hi,
I tried to compile a simple Hello_World programme in C68 with:
which gave some error messages:
Removing the -g from the command line:
the programme compiles and linked perfectly.
Is the Debug information for C68 created correctly or is it work in progress.
Needles to say GNU GDB v11 does not recognise a QL exectutable.
I tried to compile a simple Hello_World programme in C68 with:
Code: Select all
EX cc;'-v -g win1_hello_world_c -o win1_hello_world_exe -lm'
Code: Select all
EX cc;'-v -g win1_hello_world_c -o win1_hello_world_exe -lm'
Is the Debug information for C68 created correctly or is it work in progress.
Needles to say GNU GDB v11 does not recognise a QL exectutable.
Regards,
Derek
Derek
- NormanDunbar
- Forum Moderator
- Posts: 2276
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: GNU GDB
Hi derek,
looking at the C68 docs, I see this for the -g option:
-g [C68] Produce debugging information. Currently this has little effect in C68. It does, however cancel any -O option if that is also specified.
So it looks like there's a problem with that option reaching the assembler. You can, if you want to check the error in the lines mentioned, pass the -S option, the docs mention:
-S [CC] Stop after the C68 compilation phase. This will produce a file (ending in _s) which has
the assembler source produced by the compiler. Normally this is input into the AS68
assembler phase to produce the object (_o) file.
That will keep the assembler source files with the problem lines within. I suspect however, that there's no point building a debug version with the -g option. I suspect the best you will get is the use of libDebug in your programs. I've attached the C68 docs which has a section on using libDebug for your entertainment. Hope it helps.
Cheers,
Norm.
looking at the C68 docs, I see this for the -g option:
-g [C68] Produce debugging information. Currently this has little effect in C68. It does, however cancel any -O option if that is also specified.
So it looks like there's a problem with that option reaching the assembler. You can, if you want to check the error in the lines mentioned, pass the -S option, the docs mention:
-S [CC] Stop after the C68 compilation phase. This will produce a file (ending in _s) which has
the assembler source produced by the compiler. Normally this is input into the AS68
assembler phase to produce the object (_o) file.
That will keep the assembler source files with the problem lines within. I suspect however, that there's no point building a debug version with the -g option. I suspect the best you will get is the use of libDebug in your programs. I've attached the C68 docs which has a section on using libDebug for your entertainment. Hope it helps.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
-
- Font of All Knowledge
- Posts: 3971
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: GNU GDB
Hi Norman,
It looks to me that the generation of the debugging information is not implementation yet. Maybe a future development, but this will not probably happen.
I had read the C68 Library section and put the libdebug and the libmalloc, as indicated in the manual, in the cc command line did make any difference.
Maybe as the manual indicates the command: dbg_init () is required to initislise the debug data structures.
Thanks for the C68Lib PDF, I have already converted the C68 documentation to PDF, EPUB.
I find Epub more flexible than PDF, just a Epub reader on the QL...
It looks to me that the generation of the debugging information is not implementation yet. Maybe a future development, but this will not probably happen.
I had read the C68 Library section and put the libdebug and the libmalloc, as indicated in the manual, in the cc command line did make any difference.
Maybe as the manual indicates the command: dbg_init () is required to initislise the debug data structures.
Thanks for the C68Lib PDF, I have already converted the C68 documentation to PDF, EPUB.
I find Epub more flexible than PDF, just a Epub reader on the QL...
Regards,
Derek
Derek
-
- Font of All Knowledge
- Posts: 3971
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: GNU GDB
Hi,
I added the -S option to the command line for the CC command string, which gave the error as shown above, I looked in the _s file, to see what the error messages are pointing towards: the JAS messages point to the ".line " entries on lines 13, 17, 20
NOt sure what is happening here, back to the manuals I fear.
I also use CVIEW to compile single C68 files, to see the compile messages.
I added the -S option to the command line for the CC command string, which gave the error as shown above, I looked in the _s file, to see what the error messages are pointing towards: the JAS messages point to the ".line " entries on lines 13, 17, 20
NOt sure what is happening here, back to the manuals I fear.
I also use CVIEW to compile single C68 files, to see the compile messages.
Regards,
Derek
Derek
Re: GNU GDB
Derek,
the Sozobon assembler jas which is normally used by C68 to translate the _a files to _o files simply doesn't understand the directive. I guess it was planned to replace it with the GNU assembler, which does (at least, used to) support this directive. But that never happened, apparently.
the Sozobon assembler jas which is normally used by C68 to translate the _a files to _o files simply doesn't understand the
Code: Select all
.line
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: GNU GDB
For Q40/60 I had used GDB source level debugging via SER, using a "remote stub". Which is a few special-purpose subroutines that implement the GDB remote serial protocol and are linked to the executable. That was remote debugging (from a PC) and the executable was "bare metal" GCC compiled, not a QDOS program.
I could imagine that QDOS-GCC compiled C programs can be linked with a GDB remote stub as well.
I could imagine that QDOS-GCC compiled C programs can be linked with a GDB remote stub as well.