archive.worldofdragon.org

Yes, the gcc-6809 seems to work fine, granted you have the latest lwtools (my PPA had the index d,s fix added for some time before 4.11). However, there seems to be a bug (missing declaration of some sort, I think) when the compiler generates calls to its _ashlsi3 helper function, typically for shifting of 32-bit integers, like in (a << b), so check the map file to see if it has been linked in. I added a workaround for this in FUZIX. I haven't tried building newlib.

Ciaran's gdb port is an excellent tool and can do a lot. The code display is limited to disassembly, that's true. I have been playing with generating gdb scripts from the lwtools map files to remedy that a bit, but I also looked at the gdb code some days ago to see if this can be done in a more proper way. Unless we get William to add ELF or similar output to lwtools, I believe the easiest way out would be to convert the lwtools map file into something that gdb already can read symbols from. The a.out format is maybe an easier candidate than ELF.

tormod wrote:Yes, the gcc-6809 seems to work fine, granted you have the latest lwtools (my PPA had the index d,s fix added for some time before 4.11). However, there seems to be a bug (missing declaration of some sort, I think) when the compiler generates calls to its _ashlsi3 helper function, typically for shifting of 32-bit integers, like in (a << b), so check the map file to see if it has been linked in. I added a workaround for this in FUZIX. I haven't tried building newlib..

Can you elaborate on this at all? I've had a look at the map file and definitely don't have _ashlsi3 defined, I do have an assortment of others in a similar vein included though - ashlhi3 for example. It seems that _ashlsi3 is provided as part of the gcc-6809 port along with an assortment (I think they are probably resolved since I'm linking with gcc) of others however in your FUZIX build they appear to be defined in lowlevel-6809.s. My linker line is:

-o test -s default.link -b -m test.map --library-path=../gcc-install/m6809-unknown/lib/ --library-path=../gcc-install/lib/gcc/m6809-unknown/4.6.4/ ../gcc-install/m6809-unknown/lib/crt0.o $(LDFLAGS) test.o -lgcc -lc

Yes, I think you're fine if you're not using _ashlsi3. I believe _ashlhi3 and the others are correct. Yes, the ashlsi3 has been copied as-is into the FUZIX tree, from the libgcc source, so it is built without linking in the prebuilt libgcc. You should be able to reproduce the bug with a function that does (int32_t)(1 << x).

Still struggling to understand what the actual bug is though - my simple bit of code:

static long int val ;

int main ( int argc, char *argv[] )
{
long int i = 2 ;
val = (1 << i) ;

..

doesn't generate a call to _ashlhi3, the assembly code looks to be doing it in line. However newlib does have some calls to it, notably in strtod. If I include a call to that in my test code, it all builds fine but there is no reference to the _ashlihi3 call in the map file - is that what the bug is, the routine doesn't get pulled in properly?

Either way, given that this call is never invoked from the heap code & I doubt very much it's using strtod I'm probably barking up the wrong tree here and it's something else.

No, if you don't see ashlsi3 in the map file it is not linked in and you don't have to worry about this bug. The problem lies in how its parameters are prepared on the stack - it doesn't match what the routine expects.

About your code example, try having "i" as a parameter in a function, so that the compiler cannot have idea about its value.

Ah, well as I though then, it's not that causing the problem. The heap management code is way to complex to debug at the assembler level so maybe onto a hiding to nothing with this exercise. Have a feeling it's built with "O2" level optimisation so may try removing that, see if it makes a difference.

BTW, Brett from the CoCo list told me had found some optimization bugs when using -Os, concerning loop variables in some special cases. So trying different or no optimization would be a good idea.

that's the plan... once I've picked my way through the autoconf & makefile stuff.