C questions

Página 2/3
1 | | 3

Por hit9918

Prophet (2923)

Imagen del hit9918

28-11-2015, 06:47

By far the best would be source level debugging for openmsx debugger.
A debugger running on z80 itself isn't reliable. And VDP acess etc cant be debugged on the MSX itself.

A simple file format and all the rest is the job of coders converters/makefiles.

filename sourcecode
startaddress,endaddress,index_in_text
startaddress,endaddress,index_in_text
page 23
add ff00
mask 3fff
startaddress,endaddress,index_in_text
startaddress,endaddress,index_in_text

the "page" command is to make various buckets, because addresses can overlap in mapper business.
the page number isn't really a number but a string as ID.
who knows, there could be ROM mapper, or RAM mapper, or a sheme mapper*subslot.
the debuger doesn't bother all that, instead does display the bucket where the bytes of an interval match the binary.

startaddress,endaddress,index_in_text,c30000

one does not need to list all of the code of an interval.
to make it easy for converters from all sorts of .lst formats.
the end address is still needed:
an arrow displays at the index position in the text. the arrow will stay at this text index as long as the program counter matches the interval.
when no interval matches, make a question mark. show the closest matching region of the recently displayed page.
when multiple pages match, also show recent page, but show an exclamation mark Smile
change the view only when the arrow moves.
so as one is stepping and scrollbaring thru the source, the steps dont reset the view.
well some converter may get at info only per-function and that may be more than a screen high.

the "mask" does AND on both program counter and interval addresses. to match things in 16k page business.
a mask of 0xff will work with relocatible bloads.
and the add is done on the interval values only (in 16bit ring arithmethic). maybe it can help when some module started at 0 while after linking it is somewhere else.
the ADD should be done before the AND.

best is when each interval object has a mask, an add value, a pointer to string, then just run thru it statemachine style.
the commands processed in order of appearance.

Well I try to describe a little mechanism that could serve a lot of cases Smile
The rest is all the job of the converters.
It works for both asm and C.

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

28-11-2015, 06:51

hit9918 wrote:

By far the best would be source level debugging for openmsx debugger.

Sure. It would be by far the best. However, it's almost technically impossible to do source level debugging when all you have is the compiled binary code.

For openMSX to become able to do source level debugging you would have to embed a whole compiler and IDE inside openMSX.

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

28-11-2015, 08:43

o.geerdink wrote:

C is the java of MSX

Finally somebody gives a clear definition of C in MSX. Of course, I agree. :-)

Por Louthrax

Prophet (2419)

Imagen del Louthrax

28-11-2015, 11:49

JaviLM wrote:

For openMSX to become able to do source level debugging you would have to embed a whole compiler and IDE inside openMSX.

It could work by having a reference to each "C line of code" in the symbol table that openMSX loads. openMSX would display these "C lines" instead of the hex / assembly values (with the ability to switch from source code to assembly, like in Visual Studio or other modern debuggers).

Por erikmaas

Expert (67)

Imagen del erikmaas

28-11-2015, 12:48

Sdcc will make .adb and .cdb files when using the --debug option. The .cdb file contains the relevant information to do source level debugging.

Sdcdb was made for the 8051 CPU and later modified for other architectures. I tried to use it yesterday but it was not really usefull. It segfaulted. The sdcdb code really shows it was made for the 8051. Nice is that it connects to a separate simulator but gives the option to debug (via serial) on real hardware.

I think modifying the openmsx debugger might be better as Manuel suggested. Although sdcdb + ddd could give a route to debug on actual hardware.

Por hit9918

Prophet (2923)

Imagen del hit9918

28-11-2015, 13:26

this is what SDCC puts in the .lst file

                            899 ;app.c:196: void main() {
                            900 ;	---------------------------------
                            901 ; Function main
                            902 ; ---------------------------------
   0428                     903 _main_start::
   0428                     904 _main:
   0428 DD E5         [15]  905 	push	ix
   042A DD 21 00 00   [14]  906 	ld	ix,#0
   042E DD 39         [15]  907 	add	ix,sp
   0430 21 EB FF      [10]  908 	ld	hl,#-21
   0433 39            [11]  909 	add	hl,sp
   0434 F9            [ 6]  910 	ld	sp,hl
                            911 ;app.c:200: for (i = 0; i < 5; i++) { beep(); }
   0435 11 05 00      [10]  912 	ld	de,#0x0005
   0438                     913 00109$:
   0438 D5            [11]  914 	push	de
   0439 2Ar08r00      [16]  915 	ld	hl,(_beep)
   043C CDr00r00      [17]  916 	call	__sdcc_call_hl
   043F D1            [10]  917 	pop	de
   0440 1B            [ 6]  918 	dec	de
   0441 7A            [ 4]  919 	ld	a,d
   0442 B3            [ 4]  920 	or	a,e
   0443 20 F3         [12]  921 	jr	NZ,00109$
                            922 ;app.c:202: *BAKCLR = 0;
   0445 21 EA F3      [10]  923 	ld	hl,#0xF3EA
   0448 36 00         [10]  924 	ld	(hl),#0x00
                            925 ;app.c:203: screen(8); //screen8();
   044A 3E 08         [ 7]  926 	ld	a,#0x08
   044C F5            [11]  927 	push	af
   044D 33            [ 6]  928 	inc	sp
   044E CDr07r01      [17]  929 	call	_screen
   0451 33            [ 6]  930 	inc	sp

this is what I modeled the suggestion after.
grab a sourcecode line, then grab code address in next line, and grab the opcodes of that line. output a chunk in the format of the file in the other posting.
converters are relatively easy to write for all sorts of assemblers.
and PAGE / MASK commands for the address collisions that can happen on the slotted mapped MSX.

about telling the code of an interval,
one should be able to tell less code than the interval, more code (to give more clear identity when multiple chunks got same address), and "??" for places where DW variables are.
and then the arrow in the source would hop along with the debugger stepping, hop hop Smile

Por Manuel

Ascended (18873)

Imagen del Manuel

28-11-2015, 14:23

So, who takes the challenge to extend the openMSX debugger GUI to use this format and add that information? I think no changes in openMSX are needed. All you need is the current address (PC) the table from the output to look up the source line and its code (as it's in that file too).

Por PingPong

Prophet (3898)

Imagen del PingPong

28-11-2015, 20:32

JaviLM wrote:
hit9918 wrote:

By far the best would be source level debugging for openmsx debugger.

Sure. It would be by far the best. However, it's almost technically impossible to do source level debugging when all you have is the compiled binary code.

For openMSX to become able to do source level debugging you would have to embed a whole compiler and IDE inside openMSX.

No. The only requirement for a compiler is to generate a file (readable for openmsx debugger) to map source position to physical addresses for jump targets e variable memory location.
I think SDCC does this

Por PingPong

Prophet (3898)

Imagen del PingPong

28-11-2015, 20:36

Manuel wrote:

So, who takes the challenge to extend the openMSX debugger GUI to use this format and add that information? I think no changes in openMSX are needed. All you need is the current address (PC) the table from the output to look up the source line and its code (as it's in that file too).

Why not define a standard format to describe debug info and allow any target able to produce a MDI (msx debug information) to interact / interface with openmsx gui?

Por Manuel

Ascended (18873)

Imagen del Manuel

28-11-2015, 21:19

Why not use SDCC's format? It looks fine to me...

Página 2/3
1 | | 3