[ 32%] Building C object xasm/common/CMakeFiles/xasm.dir/tokens.c.o
xasm/common/tokens.c: In function 'parseSymbol':
common/tokens.c:308:9: error: 'strncpy' specified bound 257 equals destination size [-Werror=stringop-truncation]
  308 |         strncpy(lex_Current.value.string, str_String(symbolName), sizeof(lex_Current.value.string));
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

pretty sure we're dealing with a simple off-by-one here, since strncpy shouldn't copy a maximum of sizeof dest chars if it's supposed to append a \0 (which it is, since it's strncpy, not memcpy).

the same happens a bunch of other times too in xlib/library.c.

I'm taking my first stumbling steps on starting to program for the Sega Genesis, and right on the first little test I've managed to break something. I'm using asmotor on Linux.

This is my code. Note that I have not yet defined ProgramStart or IntReturn.

SECTION "INIT",CODE[0]


	DC.L	$FFFFFE00		;SP register value
	DC.L	ProgramStart	;Start of Program Code
REPT 7
	DC.L	IntReturn		; bus err,addr err,illegal inst,divzero,CHK,TRAPV,priv viol
ENDR
	DC.L	IntReturn		; TRACE
	DC.L	IntReturn		; Line A (1010) emulator
	DC.L	IntReturn		; Line F (1111) emulator
REPT 4
	DC.L	IntReturn		; Reserverd /Coprocessor/Format err/ Uninit Interrupt
ENDR
REPT 8
	DC.L	IntReturn		; Reserved
ENDR
	DC.L	IntReturn		; spurious interrupt
	DC.L	IntReturn		; IRQ level 1
	DC.L	IntReturn		; IRQ level 2 EXT
	DC.L	IntReturn		; IRQ level 3
	DC.L	IntReturn		; IRQ level 4 Hsync
	DC.L	IntReturn		; IRQ level 5
	DC.L	IntReturn		; IRQ level 6 Vsync
	DC.L	IntReturn		; IRQ level 7 
REPT 16
	DC.L	IntReturn	; TRAPs
ENDR
REPT 16
	DC.L	IntReturn	; Misc (FP/MMU)
ENDR

I'm compiling it with:

motor68k -otest.bin -fb test.asm

This outputs:

realloc(): invalid next size
[1]    4240 abort (core dumped)  motor68k -otest.bin -fb test.asm

Expected behavior: The assembler complains about undefined labels. With just some small changes, that's exactly what it does. For example if I define either ProgramStart or IntReturn, it correctly complains that the other label is undefined.

This issue was discovered while trying to put each part of the Sega Genesis ROM header in a separate, fixed location section. However, this code fails. (Just these 4 lines alone should be sufficient to repro.)

SECTION "HDR_SERIALNUMBER",DATA[$180]
	DC.B	"012345678"			;ROM serial number

SECTION "HDR_CHECKSUM",DATA[$18E]
	DC.W	$1234				;16-bit Checksum (Address $000200+)

Compile with:

motor68k -otest.bin -fb test.asm

Output:

E0131 test.asm(7): Section "" cannot be placed at $18E

However, the string in the HDR_SERIALNUMBER section is only 9 bytes long, which should not overlap the next section by a good margin. Suspecting it might be an issue with alignment of sections I also tried:

SECTION "HDR_SERIALNUMBER",DATA[$182]
	DC.B	"012345678"			;ROM serial number

SECTION "HDR_CHECKSUM",DATA[$190]
	DC.W	$1234				;16-bit Checksum (Address $000200+)

Which gave the same error. In both cases, reducing the length of the string to 8 bytes got rid of the error. However, the following worked just fine, filling every single byte up until the next section.

SECTION "HDR_SERIALNUMBER",DATA[$180]
	DC.B	"0123456789ABCDEF"			;ROM serial number

SECTION "HDR_CHECKSUM",DATA[$190]
	DC.W	$1234				;16-bit Checksum (Address $000200+)

• Fresh Linux Mint 20 install
• just installed build-essentials
• this:

marcel@marcel-linux:/asmotor_bootstrap$ sudo sh install.sh -- The C compiler identification is GNU 9.3.0 -- The CXX compiler identification is GNU 9.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/marcel/asmotor_bootstrap/build/cmake/release Scanning dependencies of target util [ 1%] Building C object util/CMakeFiles/util.dir/crc32.c.o [ 1%] Building C object util/CMakeFiles/util.dir/file.c.o [ 2%] Building C object util/CMakeFiles/util.dir/fmath.c.o [ 3%] Building C object util/CMakeFiles/util.dir/map.c.o [ 4%] Building C object util/CMakeFiles/util.dir/mem.c.o [ 5%] Building C object util/CMakeFiles/util.dir/set.c.o [ 6%] Building C object util/CMakeFiles/util.dir/str.c.o [ 7%] Building C object util/CMakeFiles/util.dir/strcoll.c.o [ 8%] Building C object util/CMakeFiles/util.dir/strbuf.c.o [ 9%] Building C object util/CMakeFiles/util.dir/strings.c.o [ 10%] Linking C static library libutil.a [ 10%] Built target util Scanning dependencies of target xasm [ 11%] Building C object xasm/common/CMakeFiles/xasm.dir/amigaobject.c.o [ 12%] Building C object xasm/common/CMakeFiles/xasm.dir/binaryobject.c.o [ 13%] Building C object xasm/common/CMakeFiles/xasm.dir/dependency.c.o [ 14%] Building C object xasm/common/CMakeFiles/xasm.dir/errors.c.o [ 15%] Building C object xasm/common/CMakeFiles/xasm.dir/expression.c.o [ 16%] Building C object xasm/common/CMakeFiles/xasm.dir/filestack.c.o [ 17%] Building C object xasm/common/CMakeFiles/xasm.dir/lexer.c.o [ 18%] Building C object xasm/common/CMakeFiles/xasm.dir/lexer_constants.c.o [ 19%] Building C object xasm/common/CMakeFiles/xasm.dir/lexer_variadics.c.o [ 20%] Building C object xasm/common/CMakeFiles/xasm.dir/linemap.c.o [ 21%] Building C object xasm/common/CMakeFiles/xasm.dir/object.c.o [ 22%] Building C object xasm/common/CMakeFiles/xasm.dir/options.c.o [ 23%] Building C object xasm/common/CMakeFiles/xasm.dir/parse.c.o [ 24%] Building C object xasm/common/CMakeFiles/xasm.dir/parse_block.c.o [ 25%] Building C object xasm/common/CMakeFiles/xasm.dir/parse_directive.c.o [ 26%] Building C object xasm/common/CMakeFiles/xasm.dir/parse_expression.c.o [ 27%] Building C object xasm/common/CMakeFiles/xasm.dir/parse_string.c.o [ 28%] Building C object xasm/common/CMakeFiles/xasm.dir/parse_symbol.c.o [ 29%] Building C object xasm/common/CMakeFiles/xasm.dir/patch.c.o [ 30%] Building C object xasm/common/CMakeFiles/xasm.dir/section.c.o [ 31%] Building C object xasm/common/CMakeFiles/xasm.dir/symbol.c.o [ 32%] Building C object xasm/common/CMakeFiles/xasm.dir/tokens.c.o In file included from /usr/include/string.h:495, from /home/marcel/asmotor_bootstrap/xasm/common/tokens.c:19: In function ‘strncpy’, inlined from ‘parseSymbol’ at /home/marcel/asmotor_bootstrap/xasm/common/tokens.c:308:9: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 257 equals destination size [-Werror=stringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[2]: *** [xasm/common/CMakeFiles/xasm.dir/build.make:336: xasm/common/CMakeFiles/xasm.dir/tokens.c.o] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:328: xasm/common/CMakeFiles/xasm.dir/all] Fehler 2 make: *** [Makefile:130: all] Fehler 2

"Fehler" (german) -> Error Had to remove ~ because of markdown.

The following code

	section "ROM", CODE[$0]
forever:
	bra forever

Produces the error foo.s68:3: E0103 Invalid source operand I believe what is happening here is that m68k_GetAddressingMode does some optimization on the addressing mode and so a bare label like forever in this example gets transformed into AM_WORD if the value of the symbol is already known and within the valid range for absolute short. The instruction table entries for the bcc family only have AM_LONG in the valid addressing mode bitfield which results in an error when this optimization is done

Simplest fix is probably just to add AM_WORD as a valid addressing mode to the bcc family, but I'm not sure if that was omitted intentionally (perhaps to forbid an explicit .w for these instructions since it doesn't make sense)

README.md says:

ASMotor is a portable and generic assembler engine and development system written in ANSI C11

but CMakeLists.txt says:

set (CMAKE_C_STANDARD 99)

Which C language standard is required—C99 or C11?

/home/moony/asmotor_bootstrap/xasm/common/parse_string.c: In function ‘stringExpressionPri1’:
/home/moony/asmotor_bootstrap/xasm/common/parse_string.c:95:25: error: ‘%0*d’ directive writing between 1 and 2147483647 bytes into a region of size 16 [-Werror=format-overflow=]
             sprintf(t, "%0*d", precision < 0 ? 0 : precision, value);
                         ^~~~
/home/moony/asmotor_bootstrap/xasm/common/parse_string.c:95:24: note: directive argument in the range [0, 2147483647]
             sprintf(t, "%0*d", precision < 0 ? 0 : precision, value);
                        ^~~~~~
In file included from /usr/include/stdio.h:873,
                 from /home/moony/asmotor_bootstrap/util/types.h:24,
                 from /home/moony/asmotor_bootstrap/util/lists.h:22,
                 from /home/moony/asmotor_bootstrap/xasm/common/patch.h:22,
                 from /home/moony/asmotor_bootstrap/xasm/common/errors.h:22,
                 from /home/moony/asmotor_bootstrap/xasm/common/parse_string.c:23:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 2 and 2147483648 bytes into a destination of size 16
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       __bos (__s), __fmt, __va_arg_pack ());
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

[ 27%] Building C object xasm/common/CMakeFiles/xasm.dir/symbol.c.o
/home/moony/projects/cpp-projects/asmotor/xasm/common/symbol.c: In function ‘callback__AMIGADATE’:
/home/moony/projects/cpp-projects/asmotor/xasm/common/symbol.c:87:27: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
     size_t stringLength = sprintf(dateString, "%d.%d.%d", localTime->tm_mday, localTime->tm_mon + 1, localTime->tm_year + 1900);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/moony/projects/cpp-projects/asmotor/xasm/common/symbol.c:87:27: note: directive argument in the range [-2147481748, 2147483647]
In file included from /usr/include/stdio.h:873,
                 from /home/moony/projects/cpp-projects/asmotor/xasm/common/symbol.c:20:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 6 and 36 bytes into a destination of size 16
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       __bos (__s), __fmt, __va_arg_pack ());
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Portfiles belong in https://github.com/macports/macports-ports only.

The PR to get the asmotor Portfile there updated is https://github.com/macports/macports-ports/pull/9663.

having noticed you didn't disallow banks on the "generic z80" target (and no way to set the bank size, so i hoped for something smart along the lines of "one binary file per bank"), i decided to check what it does with some simple code:

  SECTION "a",CODE
  DB $01
  SECTION "b",CODE[5]
  DB $02
  SECTION "c",CODE[10],BANK    ; E0100 [ expected ; (this is expected behaviour)
  DB $03
  SECTION "d",CODE[15],BANK[3] ; E0102 Invalid expression
  DB $04
  SECTION "e",CODE,BANK[3]     ; E0102 Invalid expression
  DB $05

and with motorz80 -mcz -ms0 -mu0 i'm getting the errors i commented above.

the parser seems to be totally fine with the BANK itself (and doesn't complain about banking being unsupported), but my integer is an invalid expression somehow in BANK (but totally fine in CODE).

so it seems to be failing to recognize an integer in parse_ConstantExpression (called by expectBankFixed) if i'm not mistaken.

following the control flow in those functions in my head, specifically this seems to fail:

int32_t
parse_ConstantExpression() {
    SExpression* expr = parse_Expression(4); // <-- this returns NULL??

    if (expr != NULL) {
      // ...
    } else
        err_Error(ERROR_INVALID_EXPRESSION); // <-- pretty sure I'm getting this error
    return 0;
}

Support for the SuperFX co-processor would be a welcome addition to complement the 6502 support, as it would allow the development of SuperFX accelerated SNES games using asmotor.