Package Details: tpasm 1.12-1

Git Clone URL: https://aur.archlinux.org/tpasm.git (read-only, click to copy)
Package Base: tpasm
Description: A cross assembler for 6805, 6809, 68HC11, 6502, Sunplus, 8051, Z80, PIC, AVR and c166
Upstream URL: http://www.sqrt.com/
Licenses: GPL
Submitter: None
Maintainer: uffe
Last Packager: uffe
Votes: 2
Popularity: 0.000000
First Submitted: 2012-08-07 20:30 (UTC)
Last Updated: 2023-07-10 13:26 (UTC)

Required by (0)

Sources (1)

Latest Comments

Amphitryon commented on 2021-04-14 22:23 (UTC)

I also discovered a core dump whenever tpasm reports an invalid opcode. I suspect the issue is that calling two functions from the vprintf family in with the same set of arguments is undefined behaviour. Re-working listing.c to avoid doing that seems to solve it. Here is the change as a patch:

--- tpasm/src/tpasm1.11/listing.c   2012-12-23 15:42:50.000000000 +0000
+++ tpasm.new/src/tpasm1.11/listing.c   2021-04-14 23:21:37.395031353 +0100
@@ -36,7 +36,7 @@
    va_end(args);
 }

-static void vReportMessage(const char *fileName,unsigned int lineNumber,const char *type,const char *format,va_list args)
+static void ReportBeginLine(const char *fileName,unsigned int lineNumber,const char *type)
 // report messages (errors, warnings, etc...)
 // type is a string which is descriptive of the message type
 // This will report to the stderr.
@@ -63,6 +63,11 @@
        fprintf(stderr,"<command line>         :");
    }
    fprintf(stderr,"%s: ",type);
+}
+
+static void vReportMessage(const char *fileName,unsigned int lineNumber,const char *type,const char *format,va_list args)
+{
+   ReportBeginLine(fileName, lineNumber, type);
    vfprintf(stderr,format,args);
 }

@@ -100,26 +105,30 @@
 {
    if(isError||displayWarnings)
    {
+       char string[MAX_STRING];
+       int bytes = vsnprintf(string, sizeof(string), format, args);
        if(whereFrom)
        {
-           vReportMessage(whereFrom->file?STNodeName(whereFrom->file):NULL,whereFrom->fileLineNumber,isError?"error  ":"warning",format,args);
+           ReportBeginLine(whereFrom->file?STNodeName(whereFrom->file):NULL,whereFrom->fileLineNumber,isError?"error  ":"warning");
+           fwrite(string, bytes, 1, stderr);
        }
        else
        {
-           vReportMessage(currentFile?STNodeName(currentFile):NULL,currentFileLine,isError?"error  ":"warning",format,args);
+           ReportBeginLine(currentFile?STNodeName(currentFile):NULL,currentFileLine,isError?"error  ":"warning");
+           fwrite(string, bytes, 1, stderr);
            ReportVirtualPosition();
        }
        if(listFile&&outputListing)
        {
            if(isError)
            {
-               fprintf(listFile,"**** ERROR:   ");
+               fputs("**** ERROR:   ", listFile);
            }
            else
            {
-               fprintf(listFile,"**** WARNING: ");
+               fputs("**** WARNING: ", listFile);
            }
-           vfprintf(listFile,format,args);
+           fwrite(string, bytes, 1, listFile);
        }
        if(isError)
        {

Amphitryon commented on 2021-04-14 21:11 (UTC)

To add to my own previous comment, I forgot to mention I was having the issue with 6502 assembly. I think I have found the bug. In processors/6502.c:52:

#define OP_FLAG(a,mask) ((sizeof(#a)>1)?mask:0)

should be

#define OP_FLAG(a,mask) ((sizeof(#a)>2)?mask:0)

To allow for the terminating NUL byte that sizeof includes and strlen does not.

Amphitryon commented on 2021-04-14 18:57 (UTC)

Does anyone know about bug reporting for this package? Looking on the home page for it there doesn't seem to be anything there and yet I have version 1.10 also built via AUR so there has to have been some development.

Anyway, what I am experiencing is that with v1.11 I get core dumps and also strange error messages, typically relative offset out of range on instructions that don't even use relative addressing (like JMP or LDA). Reverting to v1.10 assembles the same file without error.

stevenhoneyman commented on 2014-06-03 19:14 (UTC)

Done and updated!

stevenhoneyman commented on 2014-06-03 13:36 (UTC)

Adopted. Upstream source link seems to be dead though - I'll contact the author and try and find it.