__floatunsisf is bogus / HUNK_SYMBOL offsets do not match functions

[matthey7]

It appears that the HUNK_SYMBOL function offsets sometimes do not match the offset at the beginning of the function. This may be part of the cause of debuggers and disassemblers not being able to load symbols in some compiled executables. FindHit/FindHunkOffset type programs do not return reliable information either. The GCC6 compile of Netsurf appears to have incorrect function symbol offsets.

http://www.cy2.uk/tmp/netsurf_os3-gcc6.lha

Be warned that this executable has MuForce hits and may crash while the older GCC compile is clean with no problems. Maybe you can spot some of your compiler bugs while looking into the problem.

Example debugger which will not load symbols is BDebug from the Barfly package.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

Edit: BDebug has a bug where it does not show proper start or sizes of hunks. The GCC6 generated offsets I can now verify as correct. There is still a problem with symbols not loading from the GCC6 executable in any debugger or disassembler output but I have no valid clues why so I will close the topic. There are also MuForce hits and crashes in Netsurf likely caused by compiler bugs.

[bebbo]

Be warned that this executable has MuForce hits and may crash while the older GCC compile is clean with no problems. Maybe you can spot some of your compiler bugs while looking into the problem.

You might test if the compiler bugs are made by me and disable my optimizers using -fbbb=-. If it then runs ok I compile half objects with my optimizations, and vary until I know which object file is affected. If you could provide the preprocessed c-source I am usally able to track it down and solve it.

[matthey7]

All the -fbbb optimizations are turned off for the problematic GCC6 compiled NetSurf executable. The GCC 3.4 compiled Netsurf will load and scroll without MuForce hits and symbols are loaded by BDebug. The source is the same for both compiles. We were lucky the remainder compiler bug caused a hit but I have been unable to detect what looks like compiler problems near other hits. Lack of symbols doesn't help.

[chris-y]

Actually.. I'm not sure that's true. Certainly I did build the main executable with -fbbb=- at one point (and/or -O0), but this MuForce hit is in libnslog which I was building with the defaults. I'll rebuild it all with -fbbb=- but it might not be today.

[chris-y]

http://www.cy2.uk/tmp/netsurf_os3-fbb.lha Literally built that and haven't tried running it, don't have time!

[bebbo]

if you don't have to build so many libs first... ... and if you don't have to install so many libraries,,,

[matthey7]

The new GCC6 Netsurf build fixed the early hits in nslog_filter_ref() and nslog_filter_unref(). I get to the browser window without hits but the scrolling still does not work. There are no hits when scrolling but these did not always occur before either. I placed a breakpoint at the beginning of ami_get_vscroll_pos() offset 0x1457c4 in the current build but it never activates or stops there.

[matthey7]

I tried to catch the scroll events earlier at ami_gui_event() but there is no symbol (_ami_gui_event) for this function. Shouldn't function inlining be off for a -O0 compile or do we need GCC -fno-inline? What other reasons would cause some function symbols to be missing? Is there any way to add Amiga line debug info yet?

[chris-y]

libnslog is here: http://git.netsurf-browser.org/libnslog.git The only dependency (I think) is http://git.netsurf-browser.org/buildsystem.git (just some common makefiles NetSurf libs use) They both need building with HOST=m68k-unknown-amigaos, but you'll probably find your compiler is in the wrong place for the makefile to find it (this is why I have to create my own gcc6 build rather than using it straight from your repo) - but you should be able to manually tweak the paths for testing purposes.

ami_get_vscroll_pos() is here: http://git.netsurf-browser.org/netsurf.git/tree/frontends/amiga/gui.c#n4977 I put some debug in and ys and gwin->gw->scale are correct before the division on the last line. gwin->gw->scale is a float and set to 1.0. If ys is 0 then the result is correct, but if *ys is anything else the result is much higher than it should be - looks like it is either mis-typing the variables or overflowing for some other reason (or using the ys pointer, rather than the contents?)

PS Can this issue be re-opened so it doesn't get lost?

[chris-y]

Here is the pre-processed lexer code for nslog.

nslog_lexer.zip

[matthey7]

PS Can this issue be re-opened so it doesn't get lost?

It probably should have a new "issue" title though. I don't see any way I can change it to a better name for general Netsurf compile problems.

[bebbo]

What other reasons would cause some function symbols to be missing? static results in no symbol for the function. For the debugging purpose you might #define static it away

[matthey7]

static results in no symbol for the function. For the debugging purpose you might #define static it away

Right, and it is a static function that is missing. With "static" being a poor name anyway, I like the following trick.

#ifdef DEBUG
#define PRIVATE
#else
#define PRIVATE static
#endif

Then the functions become more readable as well as the symbols can be switched on easily.

... PRIVATE BOOL Ami_gui_event(void *w) ...

[matthey7]

I found some interesting hunk stats comparing the GCC 3.4 and GCC 6 produced executables.

Hunk # | Hunk Type | GCC3 Bytes | GCC6 Bytes
-------------------------------------------------- 
Hunk 0 HUNK_CODE 6149848 6738116
Hunk 1 HUNK_DATA 323596 106820
Hunk 2 HUNK_BSS 502096 504524

The GCC6 HUNK_DATA decreased to about 1/3 of the size in GCC3. This would be an impressive savings but is highly suspicious.

GCC 3.4 has the following HUNK_RELOC32 stats. 42500 entries to hunk 0 10821 entries to hunk 1 6244 entries to hunk 2

GCC 6 has the following HUNK_RELOC32 stats. 65535 entries to hunk 0 65535 entries to hunk 0 626 entries to hunk 0 5533 entries to hunk 1 10166 entries to hunk 2

The GCC6 executable has 131696 relocs where GCC3 had 42500 relocs for hunk 0. This is about a 3x increase which is also suspicious.

HunkFunc (http://aminet.net/package/dev/moni/HunkFunc) can list the symbols for the GCC6 executable but doesn't add them to the statistics (at the bottom with stats option) like it does for GCC3. Of course BDebug has major problems with the GCC6 executable (doesn't load symbols and breakpoints don't work) and I have not experienced problems with it loading executables before.

[matthey7]

The GCC6 compiled version of NetSurf uses soft floats. Is there any chance the soft float support code is an older compile with bugs which have been fixed since then?

The assembler code would be simpler and easier for me to spot bugs if it was compiled with 68k FPU support (68060 or 68020-68060 with FPU target), especially if I am unable to step through it with a debugger. It would be interesting to see if the ami_get_vscroll_pos() bug would go away with an FPU compile since it is floating point related.

[bebbo]

use -mhard-float

[chris-y]

Hard float version: https://www.cy2.uk/tmp/netsurf_os3-hf.lha The ami_get_vscroll_pos() bug does indeed go away in this build.

[matthey7]

void ami_get_vscroll_pos(struct gui_window_2 *gwin, ULONG *ys)
{
    if(gwin->objects[GID_VSCROLL]) {
        GetAttr(SCROLLER_Top, gwin->objects[GID_VSCROLL], ys);
    } else {
        *ys = 0;
    }

    *ys /= gwin->gw->scale;
}

GCC6 soft float

ami_get_vscroll_pos:
   movem.l a2-a3/a6,-(sp)
   move.l ($10,sp),a3
   move.l ($14,sp) a2
   move.l ($b0,a3),a0  ; Object
   tst.l a0
   beq null_obj
   move.l IntuitionBase,a6
   move.l #$85005001,d0  ; AttrID=SCROLLER_Top
   move.l a2,a1  ; StoragePtr
   jsr (GetAttr,a6)
   move.l (a2),-(sp)
   jsr __floatunsisf  ; unsigned integer convert to float?
   addq.l #4,sp
   move.l ($b8,a3),a0
   move.l ($50,a0),-(sp)
   move.l d0,-(sp)
   jsr __divsf3  ; stub function for IEEESPDiv
   addq.l #4,sp  ; tiny stack pop optimization here but looks ok to me
   move.l d0,(sp)
   jsr __fixunssfsi  ; float trunc (fintrz) and convert to unsigned integer? 
   addq.l #4,sp
   move.l d0,(a2)
   movem.l (a7)+,a2-a3/a6
   rts

null_obj:
   clr.l d0
   move.l ($b8,a3),a0
   move.l ($50,a0),-(sp)
   move.l d0,-(sp)
   jsr __divsf3
   addq.l #4,sp
   move.l d0,(sp)
   jsr __fixunssfsi
   addq.l #4,sp
   move.l d0,(a2)
   movem.l (a7)+,a2-a3/a6
   rts

The strange little stack optimization is interesting. It only saves a pre-decrement EA but delayed popping could have saved an instruction.

   move.l (a2),-(sp)
   jsr __floatunsisf
   move.l ($b8,a3),a0
   move.l ($50,a0),(sp)
   move.l d0,-(sp)
   jsr __divsf3
   addq.l #4,sp  ; tiny stack pop optimization here but looks ok to me
   move.l d0,(sp)
   jsr __fixunssfsi
   addq.l #4,sp

It still may have been better to reuse the code like the following.

ami_get_vscroll_pos:
   movem.l a2-a3/a6,-(sp)
   move.l ($10,sp),a3
   move.l ($14,sp) a2
   move.l ($b0,a3),d0  ; Object
   beq null_obj
   move.l d0,a0
   move.l IntuitionBase,a6
   move.l #$85005001,d0  ; AttrID=SCROLLER_Top
   move.l a2,a1  ; StoragePtr
   jsr (GetAttr,a6)
   move.l (a2),-(sp)
   jsr __floatunsisf
   addq.l #4,sp
null_obj:
   move.l ($b8,a3),a0
   move.l ($50,a0),-(sp)
   move.l d0,-(sp)
   jsr __divsf3
   addq.l #4,sp
   move.l d0,(sp)
   jsr __fixunssfsi
   addq.l #4,sp
   move.l d0,(a2)
   movem.l (a7)+,a2-a3/a6
   rts

Then again the code probably would not have the fluff if it had been written like the following.

void ami_get_vscroll_pos(struct gui_window_2 *gwin, ULONG *ys)
{
    if(gwin->objects[GID_VSCROLL]) {
        GetAttr(SCROLLER_Top, gwin->objects[GID_VSCROLL], ys);
            *ys /= gwin->gw->scale;
    } else {
        *ys = 0;
    }
}

Anyway, I don't see anything so it would be good to recompile the support code if old and check/test the soft float support code functions.

GCC6 hard float

ami_get_vscroll_pos:
   fmovem fp2,-(sp)
   movem.l a2-a3/a6,-(sp)
   move.l ($1c,sp),a3
   move.l ($20,sp) a2
   move.l ($b0,a3),a0  ; Object
   tst.l a0
   beq null_obj
   move.l IntuitionBase,a6
   move.l #$85005001,d0  ; AttrID=SCROLLER_Top
   move.l a2,a1  ; StoragePtr
   jsr (GetAttr,a6)
   fmove.l (a2),fp2
   tst.l (a2)
   blt wish4ui2f
   fmove.s fp2,d0  ; debugging crap or compiler intelligence? :D
   fmove.s d0,fp2
back_in:
   move.l ($b8,a3),a0
   fmove.s ($50,a0),fp0
   fdiv fp0,fp2
   fmove.s fp2,d0
   fmove.s d0,fp2
   fcmp.s #2147483648,fp2
   fbge wish4f2ui
   fintrz.s d0,fp2
   fmove.l fp2,(a2)
   movem.l (sp)+,a2-a3/a6
   fmovem (sp)+,fp2
   rts

wish4f2ui:
   fsub.s #2147483648,fp2
   fintrz fp2
   fmove.l fp2,(a2)
   add.l #$80000000,(a2)
   movem.l (sp)+,a2-a3/a6
   fmovem (sp)+,fp2
   rts

null_object:
   fmovecr #$0f,fp2  ; same as fmove.s #0,fp2 but saves 4 bytes of code while trapping on 68040-68060
   bra back_in

wish4ui2f:
   fadd.d #4294967296,fp2
   fmove.s fp2,d0
   fmove.s d0,fp2   
   bra back_in

Not good either but it works and the 68k is missing unsigned float to integer and unsigned integer to float FPU instruction variations which makes it messier than it should be.

[chris-y]

The support code is libm from clib2: https://github.com/adtools/clib2 I can upload a built version somewhere if that is useful?

[bebbo]

which math lib are you using?

If the math routines are calling the Amiga math*.libraries, I can reproduce bogus results - at least with my libs: on WinUAE.

1. open MathIeeeDoubBasBase
2. open MathIeeeSingBasBase
3. use MathIeeeDoubBasBase -> 🐛 incorrect results

For this reason libnix auto opens the singbas library before doubbas library, even if singbas is not required.

[bebbo]

no need to upload the clib2, it's using the Amiga libraries.

• are you using a real Amiga or WinUAE? (I am planning to test on my A3000, but no time to revive it...)
• have you checked your libraries?

Maybe the clib2 code needs a similar fix as the one I added to libnix https://github.com/bebbo/libnix/commit/649b9564331bcf06975e7cdf455a0f46f6a5a4a4

[chris-y]

Looks like I'm using a plain 68000 build with IEEE libs. Probably should be building for '020, but never mind that. (edit: actually I might be using an '020 build, I misread the file and am building both) clib2/libm opens singbas first: https://github.com/adtools/clib2/blob/master/library/math_init_exit.c

[matthey7]

which math lib are you using?

If the math routines are calling the Amiga math*.libraries, I can reproduce bogus results - at least with my libs: on WinUAE.

Don't trust WinUAE if the math libraries use the FPU. Frank Wille was doing some final testing for a vbcc release when I received an excited e-mail from him about bad results using some of my FPU support code. I compiled the test code on my Amiga and it was fine. He verified with his 3000 as well. Lesson learned.

1. open MathIeeeDoubBasBase 
2. open MathIeeeSingBasBase
3. use MathIeeeDoubBasBase -> bug incorrect results

For this reason libnix auto opens the singbas library before doubbas library, even if singbas is not required.

mathieeesingbas.library init sets the FPCR=$40 (rounding precision=single, rounding mode=to nearest) mathieeedoubbas.library init sets the FPCR=$90 (rounding precision=double, rounding mode=to zero)

The functions in these libraries depend on the initialized FPCR setting which means the libraries are not really compatible. Yes, it is better to have the mathieeedoubas.library init settings as it gives more precision and round to zero (trunc) is much more common in C but it is still an ugly hack that could give incorrect results with the mathieeesingbas.library functions. These libraries really should have better replacements with proper FPCR/fenv handling and more C99 math functions. However, I don't expect the ieee library limitations are the problem in ami_get_vscroll_pos().

[bebbo]

I don't expect the ieee library limitations are the problem in ami_get_vscroll_pos(). I agree, while trying to get a real solution for the baserel stuff, I'm looking into this one...

Let's look at __floatunsidf: The libgcc version uses:

float
__floatunsisf (unsigned long l)
{
  double foo = __floatunsidf (l);
  return foo;
}

So the existing unsigned long to double function is used, then double is reduced to float. But I don't understand the asm code:

___floatunsisf:
        move.l 4(sp),-(sp)
        jsr ___floatunsidf

        move.l d0,-(sp) ; wtf ? d0/d1 contains a double now
        jsr ___floatsidf  ; this kills the double

        move.l d1,(sp)
        move.l d0,-(sp)
        jsr ___truncdfsf2
        lea (12,sp),sp
        rts

📣 🐛

[bebbo]

uhm:

__floatunsisf (long unsigned int l)
...

[matthey7]

uhm:

__floatunsisf (long unsigned int l) ...

Ok. But how did __floatunsisf() work correctly with the old GCC?

Would the floating point functions fall back to using the libgcc versions if Olaf did not include them in his clib2? Perhaps linking with gcc -o test test.c -lc -lm contrary to the clib2 documentation would give the libgcc functions with the same names but may have incompatibilities?

I was just unwinding all the spaghetti of floating point calls, all 10 of them. The floatunsisf() function is missing from https://github.com/adtools/clib2/tree/master/library. I also noticed ltsf2() is the exact same code as gesf2().

P.S. I see you like to -fomit-frame-pointer for debugging also.

[bebbo]

🔩

___floatunsisf:
        move.l 4(sp),-(sp)
        jsr ___floatunsidf
        move.l d1,-(sp)
        move.l d0,-(sp)
        jsr ___truncdfsf2
        lea (12,sp),sp
        rts

Now I know why this happened: There were a ticket complaining about the size of executables and duplicate math functions. To solve this I added an #ifdef per function and enhanced the makefile fragment to compile for each function with the appropriate define.

Now __floatunsidf is no longer visible to __floatunsisf and there is no __floatunsidf prototype ...

Moving the prototypes out of the #ifdefs to the top solved this.

[bebbo]

please retest.

• floatunsisf is fixed.
• Symbols are always loaded ok using DBug.
• hunkfunc also displays the stats, can't reproduce that invalid behaviour.

[chris-y]

New build: https://www.cy2.uk/tmp/netsurf_os3-gcc6.lha The float division bug appears to be fixed, at least.

[bebbo]

Back to the symbols:

1. using m68k-amigaos-objdump -d yields a dump file with symbols and code. I checked many symbols manually and all are ok. (search >: to find them). Please tell me which code symbol is broken.

2. Symbols: 2a. Using a correct debugger (DBug) alls symbols are shown. 2b. hunkfunc emits the symbols, 11346 entries. 2c. barfly: compiled Hellogcc.c and debuged it with C-Source in BDebug.

[matthey7]

Here is the new ami_get_vscroll_pos().

ami_get_vscroll_pos:
   movem.l a2-a3/a6,-(sp)
   move.l ($10,sp),a3
   move.l ($14,sp) a2
   move.l ($b0,a3),a0  ; Object
   move.l a0,d0
   beq null_obj
   move.l IntuitionBase,a6
   move.l #$85005001,d0  ; AttrID=SCROLLER_Top
   move.l a2,a1  ; StoragePtr
   jsr (GetAttr,a6)
   move.l (a2),-(sp)
   jsr __floatunsisf  ; unsigned integer convert to float?
   addq.l #4,sp
   move.l ($b8,a3),a0
   move.l ($50,a0),-(sp)
   move.l d0,-(sp)
   jsr __divsf3  ; stub function for IEEESPDiv
   addq.l #4,sp  ; tiny stack pop optimization here but looks ok to me
   move.l d0,(sp)
   jsr __fixunssfsi  ; float trunc (fintrz) and convert to unsigned integer? 
   addq.l #4,sp
   move.l d0,(a2)
   movem.l (a7)+,a2-a3/a6
   rts

null_obj:
   clr.l d0
   move.l ($b8,a3),a0
   move.l ($50,a0),-(sp)
   move.l d0,-(sp)
   jsr __divsf3
   addq.l #4,sp
   move.l d0,(sp)
   jsr __fixunssfsi
   addq.l #4,sp
   move.l d0,(a2)
   movem.l (a7)+,a2-a3/a6
   rts

New build: https://www.cy2.uk/tmp/netsurf_os3-gcc6.lha The float division bug appears to be fixed, at least.

The nslog_filter_ref(), nslog_filter_unref(), nslog_filter_set_active(), scrolling etc. hits have returned and the performance has improved. Did some optimizations get turned on with the latest build?

Back to the symbols:

1. using m68k-amigaos-objdump -d yields a dump file with symbols and code. I checked many symbols manually and all are ok. (search >: to find them). Please tell me which code symbol is broken.

2. Symbols: 2a. Using a correct debugger (DBug) alls symbols are shown. 2b. hunkfunc emits the symbols, 11346 entries. 2c. barfly: compiled Hellogcc.c and debuged it with C-Source in BDebug.

I think the symbols are fine now. At one time I thought the offsets were off but it was because BDebug is a little fuzzy on hunk start addresses. The number of symbols is the same as GCC 3.4 which is also a good sign. BDebug still doesn't like the Netsurf executable including failing to load symbols but the cause could be any number of things. BDebug does load the large GCC 3.4 executable just fine though. One difference from the old GCC 3.4 was triple the number of HUNK_RELOC32 entries. Perhaps the following 68020+ optimization would help.

JSR .L -> BSR .B/W/L

The implicit PC relative addressing of BSR gets rid of the HUNK_RELOC32 entry and PC relative code (PIC) is generally considered more desirable. The BSR.L is faster than JSR .L on the 68040, equally fast on the 68060 and very close to the same performance on the 68020/68030 (cache case and worst case are the same performance but best case is faster for the JSR). The optimization could be turned on for 68040, 68060, 68020-68040 and 68020-68060 even if not for 68020/68030. Frank Wille's vasm assembler handles these kinds of branch optimizations brilliantly.

[bebbo]

1. With the sources from the git repo (http://source.netsurf-browser.org/netsurf.git/commit/470dce645bc9cfca1d438f62a8ffe7a6db80a278) I still get the offset $80:

   _ami_get_vscroll_pos:
       link.w a5,#0
       move.l a3,-(sp)
       move.l a2,-(sp)
       move.l 8(a5),a3
       move.l 12(a5),a2
       move.l 176(a3),d0
       jeq .L2

2. if you get a hit in

   nslog_filter_t *nslog_filter_ref(nslog_filter_t *filter)
   {
   if (filter != NULL)
       filter->refcount++;
   
   return filter;
   } 

   then a bogus pointer is passed.

3. converting jsr to bsr is not a gcc issue, it's a binutils/gas issue.

[matthey7]

1. With the sources from the git repo (http://source.netsurf-browser.org/netsurf.git/commit/470dce645bc9cfca1d438f62a8ffe7a6db80a278) I still get the offset $80:

_ami_get_vscroll_pos: link.w a5,#0 move.l a3,-(sp) move.l a2,-(sp) move.l 8(a5),a3 move.l 12(a5),a2 move.l 176(a3),d0 jeq .L2

Woops, I was tired last night and looking at ami_get_hscroll_pos() instead which is nearly identical other than the offset in the structure. The ami_get_vscroll_pos() has the correct 176 (0xb0) offset.

2. if you get a hit in

nslog_filter_t nslog_filter_ref(nslog_filter_t filter) { if (filter != NULL) filter->refcount++;

return filter; }

then a bogus pointer is passed.

Right. The pointer argument passed in is filter=0xabadf00d. NetSurf was giving these hits before when optimizations were on for part of the compile.

3. converting jsr to bsr is not a gcc issue, it's a binutils/gas issue.

Sigh. The backend could probably conditionally emit a bsr instead but it is much easier for the assembler to handle the optimization. Dr. Volker's idea to simplify the backend for vbcc was to move as many optimizations into the assembler as possible. The problem with this strategy is that the assembler doesn't know as much as the compiler so is limited in some ways on optimizations and thus part of the reason why vbcc code generation quality suffers. Still, vasm is much better than gas at optimizing and the reason why some Amiga users replace gas with vasm.

[bebbo]

ad 2. Are there hits if you apply -fbbb=-? ad 3. bsr/jsr should be handled in the asm, since the selection of bra/bsr.b/w/l must be done there. Adding code to gcc means two location to treat one issue.

[matthey7]

ad 2. Are there hits if you apply -fbbb=-?

Chris will have to answer this question (knowing the exact compiler options of each build would be helpful). It looks like optimizations for libnslog may be back causing the hits to return. There has not been a clean build of NetSurf using GCC6 yet.

ad 3. bsr/jsr should be handled in the asm, since the selection of bra/bsr.b/w/l must be done there. Adding code to gcc means two location to treat one issue.

The way it is now means zero locations to treat one issue. GAS is mostly useless at doing 68k peephole optimizations.

[bebbo]

The way it is now means zero locations to treat one issue. GAS is mostly useless at doing 68k peephole optimizations.

zero is not true.

Right now, the only missing optimization for bra/bsr is using bsr.s where possible. If a called function is not in the same source file, it's correct to use jmp/jsr. And you can force bra/bsr specifying -mscall-code.

[matthey7]

Right now, the only missing optimization for bra/bsr is using bsr.s where possible. If a called function is not in the same source file, it's correct to use jmp/jsr. And you can force bra/bsr specifying -mscall-code.

Where is the -mscall-code option documented?

Yes, it is sometimes impossible without cross module optimization to optimize a JSR to BSR. GCC has been using only one code section/hunk for the 68k where it would always be possible and GCC 3.4 seems to have been able to substantially reduce the number of HUNK_RELOC32s, assuming they mostly come from JSR, so perhaps it is possible without requiring esoteric command line options that are likely to be unused.

[chris-y]

This was built with all optimisations on. The earlier build with -fbbb=- did not have any hits according to @matthey7 - although I'm not sure if it also fixed the layout problem which I'm assuming is another float issue. I have no clue even how to figure out which code is causing that though!

[bebbo]

Where is the -mscall-code option documented? m68k-amigaos-gcc --help=target

...
-msmall-code                small code model
...

(and this isn't a new option, also gcc-2.93 had it)

@chris-y: could you provide an archive with all-you-need to build netsurf? I tried netsurf-all and got stuck at missing ...

[chris-y]

This is the best documentation I have: http://wiki.netsurf-browser.org/documentation/buildingforamigaos/ All the (non-NetSurf) dependencies are in the SDK part of the toolchain http://git.netsurf-browser.org/toolchains.git/tree/sdk There's a list of NetSurf libraries you need to build, I'll copy them into that wiki article.

You might find the pre-built toolchain has some of what you need: http://ci.netsurf-browser.org/builds/toolchains/

I don't know what netsurf-all does, I've never tried building it.

[bebbo]

wget -q -O .../tmp/toolchains/m68k-unknown-amigaos/sources/mpc-0.8.2.tar.gz http://www.multiprecision.org/mpc/download/mpc-0.8.2.tar.gz
make: *** [Makefile:232: .../tmp/toolchains/m68k-unknown-amigaos/sources/mpc-0.8.2.tar.gz] Error 8

[chris-y]

Use branch chris/gcc6-os3

[matthey7]

This was built with all optimisations on. The earlier build with -fbbb=- did not have any hits according to @matthey7 - although I'm not sure if it also fixed the layout problem which I'm assuming is another float issue. I have no clue even how to figure out which code is causing that though!

Sorry. You are correct and I was wrong. The Netsurf built with fbbb=- has no hits (starting up and scrolling) but also did not scroll correctly (only top position of scroller displayed the window). Bebbo's fix likely means NetSurf works correctly with no hits when all optimizations are off. This means we could probably try turning on compiler options until we find the problem optimization.

... -msmall-code small code model ...

I don't know why it wasn't shown in the target specific compiler options in the GCC manual on the web. In any case, the small code and even small data models are nowhere close to working with NetSurf.

[bebbo]

I don't know why it wasn't shown in the target specific compiler options in the GCC manual on the web. In any case, the small code and even small data models are nowhere close to working with NetSurf.

With my recent linker changes you can use -msmall-code with total code size >32k, since the linker inserts long intermediate jumps if needed.

[chris-y]

The layout problem is not present in the -fbb=- version. It looks like things are getting right-justified when they shouldn't be, or maybe the left margin is being set at the right edge of the page. We may need to narrow down which optimisation is causing that one, as finding the faulty code in NetSurf will be tricky.

[bebbo]

I'm first looking for the fbbb switches which work, first candidates for bugs are 'e' and 'r' :-) This reduces later the differences in the asm code.

Once I know that, I do kind of a binary search:

1. compile everything with all options enabled, keep the objects and libs.
2. compile everything with the safe options enabled. Program is working ok. Also keep objects and libs. Loop:
3. copy half of the remaining bad objects, link again and test.
4. working? goto 3.
5. not working? copy the good objects back, use only the current bad files to half and search, goto 3.

This always resulted in one file which makes the difference between working or not.

6. Compare the asm code of the good and the bad version of this file.

7. fix the bug

8. rinse and repeat.

[matthey7]

With my recent linker changes you can use -msmall-code with total code size >32k, since the linker inserts long intermediate jumps if needed.

That is a nice feature for programs which are just over the size limit for small-code but not efficient for large programs. Small Data should warn but allow 68020 programs to be over the data limit also using the full extension word format (bd,An) instead of (d16,An) which also could be faster for programs just over the size limit.

The layout problem is not present in the -fbb=- version. It looks like things are getting right-justified when they shouldn't be, or maybe the left margin is being set at the right edge of the page. We may need to narrow down which optimisation is causing that one, as finding the faulty code in NetSurf will be tricky.

I don't have a GCC6 compiled version of NetSurf without hits and the scrolling bug fixed. Maybe you recompiled the -fbbb=- build with bebbo's floating point bug fix but didn't distribute it?

Knowing which optimization causes the problem may help us know what the needle in the haystack looks like. I can catch the MuForce hit and trace it back out of the function but the chances of noticing a problem are low. It sounds like Bebbo has a good method for narrowing down the problem as I see his latest post.

[chris-y]

I don't have a GCC6 compiled version of NetSurf without hits and the scrolling bug fixed.

Neither do I, I checked the old one which was good enough to see if the layout problem was an optimisation bug.

I probably need to build OpenSSL (and Curl) with fbb=- too, to see if that is completely broken or whether gcc6 actually does build it but an optimisation is stopping it working.