Well, that explains why it doesn't work. Something must be screwed up with GCC's optimisation in the version I'm using. I'll have to try to get 4.5.4 working, but since I have a no optimisation workaround, and that's probably better for debugging, it can wait.
Sometimes less optimization is better up to a point. GCC generates aweful 68k code below -O1 or without optimizations making it tedious to read (in comparison, vbcc is nice, simple and readable with -O1) . Using registers is easier for me to read than using a stack frame also.
That would be very useful, I guess it needs a different -g option.
GCCFindHit did not work for me either so I assume that it doesn't have the debug info it needs. It should say in the docs for GCCFindHit how it needs to be compiled. I have used GCCFindHit before with success.
I've managed to get it as far as opening up the main browser window, but it's crashy crashy crashy and never loads the page. I've uploaded a new build in the same place if you want to try it under real OS3 (still testing under OS4 here as it's easier). I have noticed that you probably need to create a directory called "Users" in the NetSurf directory, as NetSurf itself never creates it (I was using CreateDirTree under OS4 but simply translated that to CreateDir for OS3 - so it misses this directory. Something to fix later.)
Some line numbers for Enforcer hits would be incredibly useful now, as I don't have a clue where to start looking to get this working further, beyond fixing the font code which I'm pretty sure is making it assert.
The first hit (byte read from 0) comes from the locale.library patch of Stricmp() in the utility.library. This is called from the asl.library which is called from NetSurf in ami_file_req_init() of amiga/file.c. The problem occurs in the second AllocAslRequest(). It looks like D0=ASL_FileRequest=0 which is correct and A0 points at the tag list which is:
A0-> 0x8008002c,0x00000001 or ASLFR_DoSaveMode,TRUE
0x8008003c,0x00000001 or ASLFR_RejectIcons,TRUE
0x80080009,0x00000000 or ASLFR_InitialDrawer,NULL
0x00000000 or TAG_DONE
The code does move your nsopt_charp to the tag list:
move.l _nsoptions,a0
move.l ($73c,a0),(-8,a5)
I believe GCC is creating the tags correctly here but a NULL pointer is moved to the data for the ASLFR_InitialDrawer tag item.
This is from the first archive. Note that hits after the first hit may be caused by earlier hits.
The second hit is a byte read from 0x85030001 which occurs in Libs:arexx.class as called from Intuition. The call originates from ami_arexx_init() in amiga/arexx.c. The second and last NewObjectA() or ARexxObject in your source is the problem. The tag list looks like:
A2-> 0x85030001,0x85030001 or AREXX_HostName,AREXX_HostName?
0x093ada24,0x095352c8 or garbage,garbage
0x000f4240,0x00000001 or garbage,garbage
0x00000014,0x234be05 or garbage,garbage
0x0230f2b7,0x0952488c or garbage,garbage
0x099ad2f0,0x091b64b8 or garbage,garbage
0x00000000 or TAG_DONE
NewObjectA() returns 0 (object creation failure?). This appears to be GCC having problems with tag lists again. ARexxClass is moved into A0 and A1 is cleared like this is a NewObjectA but then GCC seems to optimize away part of the tag list creation.
I'm going to try the new archive now as we can see that your version of GCC has a bug with tag lists.
Wtih the second archive, I'm still getting the ami_file_req_init() byte read from address 0 as described above. I then get to the screen mode requestor. I've tried a 32 bit little endian and big endian screen mode which both opened and some of the visuals were displayed before the system froze. MuForce recorded a long read from 0x12 buried (probably several functions) deep in intutition.library. This is going to be tricky to debug.
