UASM 2.51

[nidud]

deleted

[LiaoMi]

Unfortunately#31 hasn't fixed my corrupt debug info yet. Annoyingly it is only occurring on a massive project, and as I comment lines out/add back in the result changes so it's near on impossible to pin it down :(
I think I'll just have to carry on ignoring it until I can find a reproducable test case of it.

LiaoMi, I tested your MemOut file and it works fine for me with uasm32 and uasm64? Perhaps someone else can try too.

KradMoonRa, I'm thinking it's very confusing that you've got a fork going of UASM with different version numbers and the same name, perhaps we could agree on a name change for your package ?
Maybe something like Kuasm (just a thought following tradition with the naming) ?

Hi John,

thanks for testing  , you need to replace the folder with headers (http://masm32.com/board/index.php?topic=9211.msg101583#msg101583 - https://anonfiles.com/w9pdGflfu1/include_zip), then the error will appear. This bug was not present in the previous 2.50 version.

[KradMoonRa]

KradMoonRa, I'm thinking it's very confusing that you've got a fork going of UASM with different version numbers and the same name, perhaps we could agree on a name change for your package ?
Maybe something like Kuasm (just a thought following tradition with the naming) ?
[/quote]

I'm ok with name change, or a highly dev branch.
Sorry abou push for master branch with overwrite git syncked work, but I work in my dev branch, and git can't do a clear comparison with massive changes.
Right now stopped git push to master, and cancel my push merge to your repo.

[johnsa]

I'd like to spend some time with you at some point and go through the changes, maybe we can do another set of PRs in small bits back into the main UASM, I'm busy on 2.52 branch now, perhaps for 2.53
so that we can keep everything in sync. I'm quite keen to help support the work you've done on debian etc package manager / installers etc too. Perhaps we can use my hosting if it would help you out.

Applied Nidud's additional cvdbg.c changes, and now my large project no longer has the corrupt debug info. So I think that is another huge win thanks to Nidud!

My next thing to investigate there is RSP vs RBP stack frames, as these don't always show the symbol names in VS Debug. RBP is 98% correct, the the RSP ones are very far off, I'm guessing due to the different stack layout, although the dbg symbols should all have their Relative offsets stored, I'm think it might be that they're not taking RSP as their base and still trying to use RBP.

[johnsa]

LiaoMi, can you send the includes file folder directly ? That link wants me to install all sorts of chrome extensions and things

[LiaoMi]

LiaoMi, can you send the includes file folder directly ? That link wants me to install all sorts of chrome extensions and things

I sent you files via google drive  With ad blockers, I have never had ads there. Nowadays, you need to have this add-on, otherwise advertising can bring all kinds of spies.

[KradMoonRa]

I'd like to spend some time with you at some point and go through the changes, maybe we can do another set of PRs in small bits back into the main UASM, I'm busy on 2.52 branch now, perhaps for 2.53
so that we can keep everything in sync. I'm quite keen to help support the work you've done on debian etc package manager / installers etc too. Perhaps we can use my hosting if it would help you out.

We can select one or new branch of yours just to get my checks for the diverse changes by theme or fix type. For example implementation of Intel's regcall convention, as a lot of changes in code, not only for x86-64 but also for x86-32, the proc invoke assemble preproc options command-line .c files i have refactored the code for my to read it better. So my idea is I ill-do a clean off repo compare add of small themes/types batch's in one off your's new branch. This way we can track the sync changes better if you are okay with that. I'm ok with importing the packages to you space page. I have made-it for that.

[LiaoMi]

Hi John,

Memory Leak in CodeGenv2.c .. AllocInstruction() -> return malloc(sizeof(struct Instr_Def)) -> InsertInstruction(pInstr, hash) ->pInstruction Leak

Code Select Expand

void BuildInstructionTable(void)
{
uint_32 hash = 0;
struct Instr_Def* pInstrTbl = &InstrTableV2;
uint_32 i = 0;
uint_32 instrCount = sizeof(InstrTableV2) / sizeof(struct Instr_Def);

memset(InstrHash, 0, sizeof(InstrHash));

for (i = 0; i < instrCount; i++, pInstrTbl++)
{
struct Instr_Def* pInstr = AllocInstruction();
memcpy(pInstr, pInstrTbl, sizeof(struct Instr_Def));
hash = GenerateInstrHash(pInstr);
InsertInstruction(pInstr, hash);
}
}

Code Select Expand

struct Instr_Def* AllocInstruction()
{
return malloc(sizeof(struct Instr_Def));
}

Code Select Expand

void InsertInstruction(struct Instr_Def* pInstruction, uint_32 hash)
{
struct Instr_Def* curPtr = NULL;
curPtr = InstrHash[hash];
if (curPtr == NULL)
{
InstrHash[hash] = pInstruction;
return;
}
while (curPtr->next != NULL)
{
curPtr = curPtr->next;
}
curPtr->next = pInstruction;
}

strcpy vs strcpy_s - Buffer overflow errors may occur if safe functions are not used, there is no information about it even in debug build (https://en.cppreference.com/w/c/string/byte/strcpy)

Overflow with a size of 1 byte (CodeGenv2.c):
uint_32 GenerateInstrHash(struct Instr_Def* pInstruction)
{
   uint_8 hashBuffer[32];
   int len = 0;
   char* pDst = (char*)&hashBuffer;
   strcpy(pDst, pInstruction->mnemonic);

   /* String hash is case-insensitive. */
   for (int i = 0; i < strlen(pInstruction->mnemonic); i++)
   {
      hashBuffer = tolower(hashBuffer);
   }

   len += strlen(pInstruction->mnemonic);
   pDst += len;
   *(pDst + 0) = pInstruction->operand_types[0];
   *(pDst + 1) = pInstruction->operand_types[1];
   *(pDst + 2) = pInstruction->operand_types[2];
   *(pDst + 3) = pInstruction->operand_types[3];
   *(pDst + 4) = pInstruction->operand_types[4];
   len += 4;
   pDst += 4;
   return hash(&hashBuffer, len);
}

orgfixup.c memory leak

void AddOrgFixup(int curPos, int orgValue)
{
   struct orgFixup *curPtr = pOrgTable;
   struct orgFixup *pFixup = (struct orgFixup*)malloc(sizeof(struct orgFixup));
   pFixup->startPos = curPos;
   pFixup->orgValue = orgValue;
   pFixup->pNext = NULL;
   if (!curPtr)
   {
      curPtr = pFixup;
      pOrgTable = pFixup;
   }
   else
   {
      while (curPtr->pNext != NULL)
         curPtr = curPtr->pNext;
      curPtr->pNext = pFixup;
   }
   return;
}

macho64.c memory leak

int macho_build_string_tbl(struct symtab_command *pSymCmd, struct macho_module *mm)
{
   int tblSize = 0;
   int i = 0;
   struct asym *sym = NULL;
   struct strentry *pstr = NULL;
   int totalSymCount = 0;

   /* Normal local symbols */
   while (sym = SymEnum(sym, &i))
   {
      if (strcmp(sym->name, "$xdatasym") == 0) continue;
      if (sym->state != SYM_MACRO && sym->state != SYM_SEG && sym->state != SYM_TMACRO && sym->predefined == 0 && sym->state != SYM_GRP && sym->isequate == 0)
      {
         if (sym->state != SYM_EXTERNAL && !sym->ispublic && sym->used)
         {
            tblSize += strlen(sym->name) + 1;
            pstr = malloc(sizeof(struct strentry));
            memset(pstr, 0, sizeof(struct strentry));
            pstr->pstr = sym->name;
            pstr->sym = sym;
            macho_add_string(pstr, mm);
            mm->symCount++;
            totalSymCount++;
         }
      }
   }

[jj2007]

strcpy vs strcpy_s - Buffer overflow errors may occur if safe functions are not used

Coder suicide may occur if M$'s ultraslow "safe" functions are being used

(remember AsmC is about 25% faster than UAsm; if Nidud had not decided to declare "type" a non-reserved word, I would be tempted to switch...)