vbcc 0.9f release planned for April/May

[phx]

Usually I do not announce any releases, but maybe it makes sense to collect any open issues now, before I notice that there are still serious problems left after the release. As you know, a vbcc release doesn't happen so frequently.

Anybody who still has a serious problem with vbcc 0.9e or later betas, please mail me detailed examples (source text, command line options, etc.) to frank at phoenix dot owl dot de.

We will try to fix what is possible before the release.

[Leffmann]

I've been trying to reach you, but I don't think the e-mails get to you for some reason, so I'll just post it here:

Since vlink 0.15b, startup.o and startup13.o from the m68k-target will sometimes cause a guru unless you specify -Z while linking, probably because some variables initialized to zero in the data segment get converted to uninitialized BSS. Simple example to reproduce it:

//  vc -c99 -o test  test.c
#include <proto/dos.h>

int main() {  Write(Output(), "Hello!\n", 7);  }

[plasmab]

Whenever i've raised bugs with Frank they've been fixed in hours!!!

[matthey]

Originally Posted by Leffmann

Since vlink 0.15b, startup.o and startup13.o from the m68k-target will sometimes cause a guru unless you specify -Z while linking, probably because some variables initialized to zero in the data segment get converted to uninitialized BSS.

I vaguely recall that C= changed AmigaOS from not initializing BSS to initializing it to zero at some point. Perhaps my memory fails me or could this be the problem?

Edit: I believe the change was only with small data where the data and BSS hunk is combined.

[Leffmann]

Yeah you're right, Kickstart 2.0 and later will zero-fill BSS, but there's definitely an error occuring somewhere inside startup.o.

[phx]

Originally Posted by Leffmann

I've been trying to reach you, but I don't think the e-mails get to you for some reason, so I'll just post it here:

Tried both contacts? Write me the exact date and time and I will check the logs.

Since vlink 0.15b, startup.o and startup13.o from the m68k-target will sometimes cause a guru unless you specify -Z while linking, probably because some variables initialized to zero in the data segment get converted to uninitialized BSS.

Yes. Since 0.15b zero data at the end of a section are automatically removed (making it a so-called data-bss section). For Kickstart 1.x you must forbid that with -Z.

Sorry for this incompatibility. Usually new versions of vasm and vlink should be backward-compatible with old vbcc releases. vbcc 0.9f comes with new config files which include -Z.

Also startup13.o and kick13-support are removed from the m68k-amigaos target for the next release. Instead I made a complete separate target: m68k-kick13. This allows you to use a real 1.3 setup, with the original Commodore 1.3 header and matching OS-call inlines.

[Leffmann]

Thanks, I'll add -Z to my configs in the meantime.

[patrik]

Found a minor issue when compiling the old AmiCron recently.

The AmiCron code uses hex \x escapes to insert amiga escape codes into strings and sometimes that hex escape is followed by a digit.

Vbcc parses the following digit as part of the hex escape and silently overflows the char it creates from it.

Tested this with octal escapes also, but any digit following the third is simply ignored for those. Shouldn't the behavior be consistent with the hex escape?

Behavior is not consistent between other compilers for this. Gcc warns, but also overflows the char. Clang gives an error. Both have no issues with digits following octal escapes, so they also have inconsistent behavior between digits following hex and octal.

8.Ram Disk:> type escapetest.c
#include <stdio.h>
#include <string.h>
#include <ctype.h>

void printhex(const char *header, const char *string) {
        int i;

        printf("%s(%lu): ", header, strlen(string));

        for(i = 0; i < strlen(string); i++) {
                printf("%02x", (unsigned char) string[i]);
        }
        printf("\t");

        for(i = 0; i < strlen(string); i++) {
                printf("%c", isprint(string[i]) ? string[i] : '.');
        }
        printf("\n");
}

int main(void) {
        printhex("hextest1", "test");
        printhex("hextest2", "\x74est");
        printhex("hextest3", "\x74""est");
        printhex("hextest4", "\x74e1st");

        printhex("octaltest1", "l33t");
        printhex("octaltest2", "\15433t");
        printhex("octaltest3", "\154""33t");

        return 0;
}
8.Ram Disk:> vc -o escapetest escapetest.c
8.Ram Disk:> escapetest
hextest1(4): 74657374   test
hextest2(3): 4e7374     Nst
hextest3(4): 74657374   test
hextest4(3): e17374     ást
octaltest1(4): 6c333374 l33t
octaltest2(4): 6c333374 l33t
octaltest3(4): 6c333374 l33t

[paraj]

Originally Posted by patrik

Found a minor issue when compiling the old AmiCron recently.

The AmiCron code uses hex \x escapes to insert amiga escape codes into strings and sometimes that hex escape is followed by a digit.

Vbcc parses the following digit as part of the hex escape and silently overflows the char it creates from it.

Tested this with octal escapes also, but any digit following the third is simply ignored for those. Shouldn't the behavior be consistent with the hex escape?

Behavior is not consistent between other compilers for this. Gcc warns, but also overflows the char. Clang gives an error. Both have no issues with digits following octal escapes, so they also have inconsistent behavior between digits following hex and octal.

8.Ram Disk:> type escapetest.c
#include <stdio.h>
#include <string.h>
#include <ctype.h>

void printhex(const char *header, const char *string) {
        int i;

        printf("%s(%lu): ", header, strlen(string));

        for(i = 0; i < strlen(string); i++) {
                printf("%02x", (unsigned char) string[i]);
        }
        printf("\t");

        for(i = 0; i < strlen(string); i++) {
                printf("%c", isprint(string[i]) ? string[i] : '.');
        }
        printf("\n");
}

int main(void) {
        printhex("hextest1", "test");
        printhex("hextest2", "\x74est");
        printhex("hextest3", "\x74""est");
        printhex("hextest4", "\x74e1st");

        printhex("octaltest1", "l33t");
        printhex("octaltest2", "\15433t");
        printhex("octaltest3", "\154""33t");

        return 0;
}
8.Ram Disk:> vc -o escapetest escapetest.c
8.Ram Disk:> escapetest
hextest1(4): 74657374   test
hextest2(3): 4e7374     Nst
hextest3(4): 74657374   test
hextest4(3): e17374     ást
octaltest1(4): 6c333374 l33t
octaltest2(4): 6c333374 l33t
octaltest3(4): 6c333374 l33t

I think this is consistent with the standard[0]. From §6.4.4.4 section 14:

14 EXAMPLE 3 Even if eight bits are used for objects that have type char, the construction '\x123'
specifies an integer character constant containing only one character, since a hexadecimal escape sequence
is terminated only by a non-hexadecimal character. To specify an integer character constant containing the
two characters whose values are '\x12' and '3', the construction '\0223' may be used, since an octal
escape sequence is terminated after three octal digits. (The value of this two-character integer character
constant is implementation-defined.)

[0]: http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf Not the actual C99 standard (as that costs money) but should be close enough. C++ is similar.

[patrik]

Ok, so even the standard seems to promote inconsistent behavior, it would be nice with a warning so you notice it at compile time instead of after.

[paraj]

Originally Posted by patrik

Ok, so even the standard seems to promote inconsistent behavior, it would be nice with a warning so you notice it at compile time instead of after.

I'm speculating, but since it seems like it'd be very easy to warn about*, there's probably a reason (too much working code out there relying on the behavior) for it not to already be present in GCC/Clang. But you should consider suggesting it to your favorite compiler implementer, they may just be missing the request.

*) OTOH the check might be costly compared to the frequency of the associated (potential) error.

[patrik]

Originally Posted by paraj

I'm speculating, but since it seems like it'd be very easy to warn about*, there's probably a reason (too much working code out there relying on the behavior) for it not to already be present in GCC/Clang. But you should consider suggesting it to your favorite compiler implementer, they may just be missing the request.

gcc warns about about it:

$ gcc -o escapetest escapetest.c
escapetest.c: In function ‘main’:
escapetest.c:23:23: warning: hex escape sequence out of range
  printhex("hextest2", "\x74est");
                       ^

clang gives an error:

 clang -o escapetest escapetest.c
escapetest.c:23:24: error: hex escape sequence out of range
        printhex("hextest2", "\x74est");
                              ^~~~~
1 error generated.

My most used C compiler is vbcc, please consider this a request =).

[Cowcat]

Vlink blues

Seems like newer versions of vlink (to vlink 15d) have weird issues with my old Quake2 sources -> final executable crashes whenever the dll's are loading .

Vlink v.15 ( build date dec 30 2104 ), seems to work ok (bouth for 68k & warpos).

Newer vlink(s) need some special toggle with programs that rely on dynamic libs or something is broken ?

[phx]

Originally Posted by patrik

        printhex("hextest2", "\x74est");

My most used C compiler is vbcc, please consider this a request =).

Sorry, missed that.

We are checking your request. Makes sense to issue a warning, IMHO.

[phx]

Originally Posted by Cowcat

Seems like newer versions of vlink (to vlink 15d) have weird issues with my old Quake2 sources -> final executable crashes whenever the dll's are loading .

Which target? PPC? WarpOS? Or 68k hunk format?

I don't know how these DLLs are generated or used, so I can only make a quick guess: Since 0.15b zero-bytes at the end of a section are automatically stripped. The total size of the section stays the same, but initialized (stored in the file) data size becomes smaller.

This caused some problems, because you cannot easily replace vlink in vbcc0.9e or older with such a version.

Try to add the -Z option (available since vlink 0.15d) to your vlink-call. This should restore the old behaviour.

Otherwise, write me a mail with a reproducible example.

[Cowcat]

Try to add the -Z option (available since vlink 0.15d) to your vlink-call

Good guess ! That fixes the issue

Those "dll" are simple object files joined together with a lib (dll.lib in this case) linked to them as well the principal main program (quake2 executable). Nothing fancy: vbcc compiles them with no problem as individual "programs". Just notice than the principal exec doesn't need those extra bytes but anyway, case resolved.

[matthey]

Originally Posted by Cowcat

Those "dll" are simple object files joined together with a lib (dll.lib in this case) linked to them as well the principal main program (quake2 executable). Nothing fancy: vbcc compiles them with no problem as individual "programs". Just notice than the principal exec doesn't need those extra bytes but anyway, case resolved.

DLL usually stands for Dynamically Linked Library which is linked at run time (Windows .dll and Unix .so files) but a vbcc .lib file is a statically linked object linked at compile time. This makes a file called dll.lib a rather confusing name .

[Cowcat]

...technically those Q2 vbcc files when applying the dll.lib, are "DLLs" and.... Things are confusing nowadays (well, 15 years ago )

[matthey]

Originally Posted by Cowcat

...technically those Q2 vbcc files when applying the dll.lib, are "DLLs" and.... Things are confusing nowadays (well, 15 years ago )

I figured the dynamically linked library was turned into a statically linked library. Statically linking is simpler and less likely to cause problems. The dll.lib name probably could have been more descriptive though.

[emufan]

gcc6 supports/creates now amiga hunk format.

Originally Posted by bebbo

Yes.[*]The aout specific constructors via .stab/.stabstr are supported in amiga-hunk-format: the content is passed in debug sections and processed by the linker.[/LIST]

I'm building a LW plugin, which atm refuses to link, so i tried vlink (0.16a):

vlink  *.o -o plugin.p -Llib/ lib/server.lib 
Fatal error 17: 3D.o: Misplaced HUNK_DEBUG in 3D.o.

I can see the 03F1 within .stab/.stabstr sections. so this might be an unspported feature?!

00001a80  65 33 34 61 72 65 61 45  76 00 00 00 00 00 13 a4  |e34areaEv.......|
00001a90  00 00 00 00 00 00 03 f2  00 00 03 e8 00 00 00 02  |................|
00001aa0  2e 64 61 74 61 00 00 00  00 00 03 ea 00 00 00 06  |.data...........|
00001ab0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001ac0  00 00 00 00 00 00 00 00  00 00 03 f2 00 00 03 e8  |................|
00001ad0  00 00 00 01 2e 62 73 73  00 00 03 eb 00 00 00 01  |.....bss........|
00001ae0  00 00 03 f2 00 00 03 e8  00 00 00 02 2e 73 74 61  |.............sta|
00001af0  62 00 00 00 00 00 03 f1  00 00 00 0c 00 00 00 01  |b...............|
00001b00  16 00 00 00 00 00 14 d4  00 00 00 10 16 00 00 00  |................|
00001b10  00 00 14 f0 00 00 00 1f  18 00 00 00 00 00 00 00  |................|
00001b20  00 00 00 34 16 00 00 00  00 00 15 08 00 00 03 ec  |...4............|
00001b30  00 00 00 03 00 00 00 00  00 00 00 08 00 00 00 14  |................|
00001b40  00 00 00 2c 00 00 00 01  00 00 00 01 00 00 00 20  |...,........... |
00001b50  00 00 00 00 00 00 03 f2  00 00 03 e8 00 00 00 02  |................|
00001b60  2e 73 74 61 62 73 74 72  00 00 03 f1 00 00 00 12  |.stabstr........|
00001b70  00 5f 5f 5f 43 54 4f 52  5f 4c 49 53 54 5f 5f 00  |.___CTOR_LIST__.|
00001b80  5f 5f 5f 44 54 4f 52 5f  4c 49 53 54 5f 5f 00 5f  |___DTOR_LIST__._|
00001b90  5f 45 48 5f 46 52 41 4d  45 5f 4f 42 4a 45 43 54  |_EH_FRAME_OBJECT|
00001ba0  53 5f 5f 00 5f 5f 45 48  5f 46 52 41 4d 45 5f 42  |S__.__EH_FRAME_B|
00001bb0  45 47 49 4e 53 5f 5f 00  00 00 03 f2              |EGINS__.....|
00001bbc

hunktool gives me some similiar error, but I have no idea who's the author:

 hunktool  info 3D.o
3D.o (0.0000s) BUILD SEGMENTS FAILED: Expected main hunk in unit: HUNK_DEBUG 1009/3f1

maybe I'm doing soemthing wrong or it's a missing feature, just reporting.