We need an iBrowse replacement for 68k!!!

[wawrzon]

ive got a feeling too, there must be some simple method to find and fix those problems rather than going round in circles.

[Heiroglyph]

ive got a feeling too, there must be some simple method to find and fix those problems rather than going round in circles.

And this is in no way a criticism of Chris. He's done a great service to the community at much personal expense.

I just think that the process needs to be fixed for the new platform.

[chris]

It's still not working without direct_render:1 in Choices.

Edit: I just verified that the new version has a hit in the same place.

Different function hopefully, as I've taken the RectFill out.

[chris]

This can't seriously be how you intend to debug the whole application. It's just not viable.

I agree. It wasn't my intention to debug it like this, I was rather hoping somebody would start building it and be able to debug/fix it more efficiently. Also it would help if gstabs/gccfindhit actually worked.

[wawrzon]

And this is in no way a criticism of Chris. He's done a great service to the community at much personal expense.

I just think that the process needs to be fixed for the new platform.

neither on my part but i would like to be able to follow some systematic process of debugging to learn and be able to utilize this method elsewhere.

edit: we need someone experiences with debugging on 68k, bernd was such a person as it seems, but he had some mystery commercial debugger.. would be great to be able to debug gcc generated binaries though. not everything can be easily ported to vbcc.

[ChaosLord]

I haven't read the thread and I'm not going to.

If I have said it once I have said it 4096 times:

Please, for the love of Jay Miner & Mitchy, use the SASC SOURCE LEVEL Debugger!  It is light-years ahead of anything else for Amiga and will save you thousands of hours of time.  That is not an exaggeration.  I mean it will literally save you 2000+ hours of time when working on large projects.

You can thank me later.

[wawrzon]

I fear netsurf as aros and many other çontemporary projects may be dependant on gcc features a compiler from the nineties does not offer.

[matthey]

I've been following along daily but had no time to actually look at it myself.

This can't seriously be how you intend to debug the whole application. It's just not viable.

This needs to be built with source level debugging one way or another.

It's not viable in the long run but it is the quickest method to get NetSurf up and partially usable. Even if Chris had a better compiler and debugger, his hardware may not be adequate and that takes time to sort out or upgrade.

My suggestion is still to get it building with VBCC so that you can use a source level debugger such as the one in SAS/C.

It couldn't take longer than debugging like this and the final result will be more reliable.

Vbcc has a clear advantage for debugging because BDebug (Barfly package) and CPR (SAS/C) are good debuggers which can be used. Vbcc is not a drop in replacement for GCC though. It is missing some C99 support like inttypes.h which NetSurf is using. I have created and tested an experimental inttypes.h and updated stdint.h which is currently being evaluated by Frank and Volker:

http://www.heywheel.com/matthey/Amiga/new_c_headers.lha

I may have already posted a link to some fixes for the C99 math libs:

http://eab.abime.net/showthread.php?t=74692

Vbcc has pretty good C99 support (requires -c99 switch) but it doesn't have all the GCC posix and unix bloat by default. Rather than libnix or the nasty ixemul, Frank's posix.lib is usually used if this functionality is needed. The includes are a bit tricky sometimes but the posix.lib is Amiga friendly and has worked well for me the couple of times I have used it for small projects. It is actively maintained as is vbcc.

http://aminet.net/dev/c/vbcc_PosixLib.lha http://aminet.net/package/dev/c/vbcc_PosixLib

It has some bsdsocket.library functions of which the following is written in the readme,

"Since 2.0 it also includes the most important TCP/IP network functions, which are implemented through bsdsocket.library (only opened when really needed!). The main advantages in combining bsdsocket with PosixLib is the possibility to use a common set of file- and socket-descriptors as well as clean header files which don't conflict with vbcc's standard headers."

I wonder if it would work offline unlike clib? It is probably worth checking out if most of the functions needed in NetSurf are available.

There would be some work involved in compiling also, Vbcc is strict by default about C standards where GCC by default is too sloppy and forgiving. Vbcc will often warn about questionable code that usually should be fixed. Vbcc may not be a quick and easy way to get better Amiga debugging but the support is good .

@Chris
Is a new version of NetSurf available to test without RectFill?

[chris]

@Chris
Is a new version of NetSurf available to test without RectFill?

The most recent one I uploaded had that removed (well, replaced with EraseRect).  I'm looking at the archive now, NetSurf executable size is 5906380 dated 13-02-2015 18:38.

[chris]

I fear netsurf as aros and many other çontemporary projects may be dependant on gcc features a compiler from the nineties does not offer.

Even gcc 2.95 was deemed too old/troublesome when I mentioned it.

[matthey]

The most recent one I uploaded had that removed (well, replaced with EraseRect).  I'm looking at the archive now, NetSurf executable size is 5906380 dated 13-02-2015 18:38.

That is the executable I'm using. Let me do some more debugging and I'll try to see what is going on.

Edit: Let me walk through the debugging process for people who want to learn a little about debugging. I set the stack up in the shell and changed to the NetSurf directory. I then entered:

>BDebug NetSurf -v

In the little BDebug window I selected "Crashed" (same as Catch Crashed Task in the Menu) and selected "Special->Catch Enforcer Hits" in the menu (this works with MuForce also). This will cause BDebug to stop at the problem if we don't make it to where we want to debug. I now select "Info Tools->Open Symbol Window" in the menu. I scroll down in this new window until I get to _ami_plot_clear_bbox (function names have an underscore in front of them). I then double click on this symbol and I will be asked if I want to "Jump to location?" which I select "Ok" opening a code window with the start of the function at the top. With this window active I select in the menu "Specials->Set/Clear Breakpoint" and the top line of the function and window will turn white where the break point is set. I now select in the menu "Step/Trace->Run Task" which causes the program to begin execution until a breakpoint, hit or crash occurs. I didn't have any hits up to the breakpoint and it looks like the first use of the function is where I need it to be judging by the NetSurf debug output. I now step down to "MOVE.L _GfxBase,A6" using the menu "Step/Trace->Trace over Calls" or right Amiga 't'. This skips over any functions calls to get to the "JSR EraseRect(A6)" graphics.library call we want to examine. It may be necessary to select in the menu "Configuration->Guess Lib Call" to see the "EraseRect" instead of an offset (Symbols and Show Lib Call above Guess Lib Call in the menu should already be toggled on by default).  Now I trace with right Amiga 't' until the "JSR EraseRect(A6)" is white right before branching into the library. I now look at the status window which shows the register values. The interesting values for EraseRect() from the AmigaOS 3.9 NDK are:

A1=093bb2b4 (rp)
D0=00000008 (xmin)
D1=00000034 (ymin)
D2=00000318 (xmax)
D3=0000024b (ymax)

Note that these values are in hexadecimal even though they are not marked with '$' or "0x".

Everything looks ok so far as (xmax >= xmin), (ymax >= ymin) and the rp address looks valid. Perhaps the rp is corrupt or non-ititialized correctly? I will now step into the graphics.library EraseRect() to see what is wrong and try to verify what I saw before with the hit inside but this is more advanced debugging and beyond what most programmers would do. If line debug source info was available in the NetSurf executable, we could select in the menu "Windows->Open SourceWindow" and we could have watched each line of source executed starting at the top of ami_plot_clear_bbox() but not when we branch into the AmigaOS. I'll go ahead and post what I have so far.

Edit2: I'm going in. I have the line "JSR EraseRect(A6)" highlighted in white and instead of right Amiga 't' to trace over this routine I use right Amiga 's' which traces along the Program Counter (PC) route one instruction after the next. We have an absolute jmp in the library function table and then we are in the graphics.library EraseRect(). The code first checks if rp==NULL and then saves some registers to the stack with MOVEM. The rp->Layer is then moved to A5 in preparation for a "JSR LockLayerRom(A6)" which is where the hit occurs. It looks like there may be an ObtainSemaphore() of the Layer_info->SignalSemaphore and then the AddTail() of the Layer_info->gs_Head list is corrupt and causes the hit before going to sleep with Wait(). The Layer_info is all !! Private !! data so it is unlikely that NetSurf directly messed up the list. I believe the rp->Layer or the whole RastPort is corrupt or not initialized properly.

[chris]

I believe the rp->Layer or the whole RastPort is corrupt or not initialized properly.

Seems unlikely, however I've just discovered some code I stuck in for OS3 only which may well be causing the problem, so I've taken that out and uploaded a new version.

[matthey]

Seems unlikely, however I've just discovered some code I stuck in for OS3 only which may well be causing the problem, so I've taken that out and uploaded a new version.

It's working again .

[chris]

It's working again .

Woo-hoo!

Is the graphical corruption still present?

[matthey]

Is the graphical corruption still present?

The welcome page looks good but amiga.org still has gfx corruption.

[chris]

The welcome page looks good but amiga.org still has gfx corruption.

OK, that's unlikely to get fixed any time soon.