GNU GDB

Anything QL Software or Programming Related.
Post Reply
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

GNU GDB

Post by Derek_Stewart »

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...


Regards,

Derek
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: GNU GDB

Post by NormanDunbar »

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.


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.
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: GNU GDB

Post by mk79 »

NormanDunbar 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.
Maybe that's why the FET command was invented ;)

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


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: GNU GDB

Post by NormanDunbar »

mk79 wrote:Maybe that's why the FET command was invented ;)
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:But I personally would just use "JMON win1_blah_exe".
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.

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.
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: GNU GDB

Post by Derek_Stewart »

Hi,

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'
which gave some error messages:
C68 -g debug error
C68 -g debug error
C68 Debug.png (6.33 KiB) Viewed 1698 times
Removing the -g from the command line:

Code: Select all

EX cc;'-v -g win1_hello_world_c -o win1_hello_world_exe -lm'
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.


Regards,

Derek
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: GNU GDB

Post by NormanDunbar »

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.
C68_lib.pdf
(508.69 KiB) Downloaded 47 times
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.
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: GNU GDB

Post by Derek_Stewart »

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...


Regards,

Derek
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: GNU GDB

Post by Derek_Stewart »

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:
C68 QD-DEBUB aseembler file
C68 QD-DEBUB aseembler file
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
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: GNU GDB

Post by tofro »

Derek,

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
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.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: GNU GDB

Post by Peter »

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.


Post Reply