nasm-devel — NASM development work

Re: [Nasm-devel] introduction

[Frank K. <fbk...@my...>]

Jim Kukunas wrote:
> Hi Folks,
> 
> Just wanted to make a quick introduction ...
> 
> My name is Jim Kukunas, and I work within Intel's Open Source Technology Center
> (OTC). I'm going to be helping hpa with some maintence and enablement type work.
> 
> Looking forward to working with you guys.

Hi Jim,

Thanks for helping out with Nasm! (I'm nominally a "developer" but 
mostly just a "fan". I appreciate the work you guys do keeping Nasm up 
to date and running smoothly!)

Best,
Frank

Re: [Nasm-devel] introduction

[Cyrill G. <gor...@gm...>]

On Thu, Aug 07, 2014 at 10:10:32PM -0700, Jim Kukunas wrote:
> Hi Folks,
> 
> Just wanted to make a quick introduction ...
> 
> My name is Jim Kukunas, and I work within Intel's Open Source Technology Center
> (OTC). I'm going to be helping hpa with some maintence and enablement type work.
> 
> Looking forward to working with you guys.

Warm welcome, Jim!

[Nasm-devel] introduction

[Jim K. <jam...@li...>]

Hi Folks,

Just wanted to make a quick introduction ...

My name is Jim Kukunas, and I work within Intel's Open Source Technology Center
(OTC). I'm going to be helping hpa with some maintence and enablement type work.

Looking forward to working with you guys.

-- 
Jim Kukunas
Intel Open Source Technology Center

Re: [Nasm-devel] [nasm:master] debug: Drop LOGALLOC usage

[Cyrill G. <gor...@gm...>]

On Sun, May 11, 2014 at 01:03:35PM -0700, anonymous coward wrote:
> > debug: Drop LOGALLOC usage
> >
> > There are special tools (like valgrind and etc)
> > to track memory leaks, no need for own trivial
> > tracker.
> 
> I hereby request that this change be undone.
> 
> This functionality has found bugs in the past.
> Not everyone has the patience to mess with
> third party memory tracking tools. And, last
> but not least, this code does not seem to be
> a maintenance nightmare.

Well, the idea of all this initiative is to shrink the nasm code moving out
all unneeded parts. Frankly I believe we should not carry the things which
are known to be handled a way better by mem-tracking tools. Moreover you
don't need much patience to work with say valgrind. Just compile nasm with
debug info and it inform you the places which are leaking memory.

[cyrill@moon nasm.git] valgrind --leak-check=full --show-reachable=yes ./nasm -fbin br3392278.asm 
==32117== Memcheck, a memory error detector
==32117== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==32117== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==32117== Command: ./nasm -fbin br3392278.asm
==32117== 
==32117== 
==32117== HEAP SUMMARY:
==32117==     in use at exit: 143 bytes in 6 blocks
==32117==   total heap usage: 4,861 allocs, 4,855 frees, 1,531,217 bytes allocated
==32117== 
==32117== 1 bytes in 1 blocks are still reachable in loss record 1 of 3
==32117==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32117==    by 0x4075F4: nasm_malloc (nasmlib.c:109)
==32117==    by 0x402AAD: quote_for_make (nasm.c:583)
==32117==    by 0x40189A: main (nasm.c:373)
==32117== 
==32117== 14 bytes in 1 blocks are still reachable in loss record 2 of 3
==32117==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32117==    by 0x407758: nasm_strdup (nasmlib.c:180)
==32117==    by 0x40871C: src_get (nasmlib.c:640)
==32117==    by 0x40DD27: out (assemble.c:343)
==32117==    by 0x410F33: gencode (assemble.c:1767)
==32117==    by 0x40DA2E: assemble (assemble.c:663)
==32117==    by 0x404FF8: assemble_file (nasm.c:1743)
==32117==    by 0x401D38: main (nasm.c:473)
==32117== 
==32117== 128 bytes in 4 blocks are definitely lost in loss record 3 of 3
==32117==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32117==    by 0x4075F4: nasm_malloc (nasmlib.c:109)
==32117==    by 0x44B969: pp_reset (preproc.c:4884)
==32117==    by 0x403009: assemble_file (nasm.c:1227)
==32117==    by 0x401D38: main (nasm.c:473)
==32117== 
==32117== LEAK SUMMARY:
==32117==    definitely lost: 128 bytes in 4 blocks
==32117==    indirectly lost: 0 bytes in 0 blocks
==32117==      possibly lost: 0 bytes in 0 blocks
==32117==    still reachable: 15 bytes in 2 blocks
==32117==         suppressed: 0 bytes in 0 blocks
==32117== 
==32117== For counts of detected and suppressed errors, rerun with: -v
==32117== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
[cyrill@moon nasm.git]

Re: [Nasm-devel] [nasm:master] debug: Drop LOGALLOC usage

[anonymous c. <nas...@us...>]

> debug: Drop LOGALLOC usage
>
> There are special tools (like valgrind and etc)
> to track memory leaks, no need for own trivial
> tracker.

I hereby request that this change be undone.

This functionality has found bugs in the past.
Not everyone has the patience to mess with
third party memory tracking tools. And, last
but not least, this code does not seem to be
a maintenance nightmare.

Re: [Nasm-devel] Does it worth to carry rdoff format?

[<p1...@ja...>]

I see no reason to maintain an object format that is of very limited 
use, if even used at all.  Speaking solely from my own +30 years 
experience I'm +1 with dropping it - not that I have much say in the 
matter anyways. :)
Rob

On 5/9/2014 2:30 PM, H. Peter Anvin wrote:
> On 05/09/2014 09:20 AM, Cyrill Gorcunov wrote:
>> At the moment I walking throught the sources looking for parts of code
>> which can be ripped off. One of them -- custom malloc/free tracker.
>> There are a bunch to memory trackers (valgrind and such) so I think
>> we don't need our trivial one.
>>
> By the way, thank you for looking into this.  Cruft accumulates in a
> code base over time.
>
> 	-hpa
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Nasm-devel mailing list
> Nas...@li...
> https://lists.sourceforge.net/lists/listinfo/nasm-devel
>

[Nasm-devel] nasm-2.11.xx maintenance branch

[H. P. A. <hp...@zy...>]

Hi all,

I have tagged nasm-2.11.04 for release, and created a nasm-2.11.xx
maintenance branch.  The goal of this is for the master branch to turn
into a future 2.12 branch with the kind of changes we don't necessarily
want in a maintenance release.  That being said, I think I might have
erred too much on the side of caution: Cyrill's --v patch probably is
stable material, so I have cherry-picked it onto the stable branch (it
didn't make it into 2.11.04, though.)

	-hpa

Re: [Nasm-devel] Does it worth to carry rdoff format?

[H. P. A. <hp...@zy...>]

On 05/09/2014 09:20 AM, Cyrill Gorcunov wrote:
> 
> At the moment I walking throught the sources looking for parts of code
> which can be ripped off. One of them -- custom malloc/free tracker.
> There are a bunch to memory trackers (valgrind and such) so I think
> we don't need our trivial one.
> 

By the way, thank you for looking into this.  Cruft accumulates in a
code base over time.

	-hpa

Re: [Nasm-devel] Does it worth to carry rdoff format?

[Cyrill G. <gor...@gm...>]

On Fri, May 09, 2014 at 09:27:59AM -0700, H. Peter Anvin wrote:
> On 05/09/2014 09:20 AM, Cyrill Gorcunov wrote:
> >>
> >> We kind of have the same problem with NASM as with Linux... the only way
> >> to really find out what is being used is to break it...!
> > 
> > Well, we can try it then -- drop rdoff by _one_ commit, and if people
> > start complaing about it, we simply revert the commit.
> > 
> > At the moment I walking throught the sources looking for parts of code
> > which can be ripped off. One of them -- custom malloc/free tracker.
> > There are a bunch to memory trackers (valgrind and such) so I think
> > we don't need our trivial one.
> 
> I'm wondering how much problem it causes, though.  Doing some web
> searches seems to imply there are some scattered users out there.  We
> haven't spent a lot of time working on it for a very long time, so it
> doesn't seem to be causing problems, as far as I can tell.

You're talking about rdoff or mem-tracker? ;)

Re: [Nasm-devel] Does it worth to carry rdoff format?

[H. P. A. <hp...@zy...>]

On 05/09/2014 09:20 AM, Cyrill Gorcunov wrote:
>>
>> We kind of have the same problem with NASM as with Linux... the only way
>> to really find out what is being used is to break it...!
> 
> Well, we can try it then -- drop rdoff by _one_ commit, and if people
> start complaing about it, we simply revert the commit.
> 
> At the moment I walking throught the sources looking for parts of code
> which can be ripped off. One of them -- custom malloc/free tracker.
> There are a bunch to memory trackers (valgrind and such) so I think
> we don't need our trivial one.
> 

I'm wondering how much problem it causes, though.  Doing some web
searches seems to imply there are some scattered users out there.  We
haven't spent a lot of time working on it for a very long time, so it
doesn't seem to be causing problems, as far as I can tell.

	-hpa

Re: [Nasm-devel] Does it worth to carry rdoff format?

[Cyrill G. <gor...@gm...>]

On Fri, May 09, 2014 at 09:11:20AM -0700, H. Peter Anvin wrote:
> On 05/09/2014 09:10 AM, Cyrill Gorcunov wrote:
> > On Fri, May 09, 2014 at 08:56:27AM -0700, H. Peter Anvin wrote:
> >> On 05/09/2014 12:48 AM, Cyrill Gorcunov wrote:
> >>> Hi, it seems rdoff is not that popular nowadays. Maybe we should
> >>> drop it off? Are there still active users?
> >>
> >> It is hard to say.  I suspect it is actually not the least used of the
> >> formats we support... :-/
> > 
> > I see. OK then.
> 
> We kind of have the same problem with NASM as with Linux... the only way
> to really find out what is being used is to break it...!

Well, we can try it then -- drop rdoff by _one_ commit, and if people
start complaing about it, we simply revert the commit.

At the moment I walking throught the sources looking for parts of code
which can be ripped off. One of them -- custom malloc/free tracker.
There are a bunch to memory trackers (valgrind and such) so I think
we don't need our trivial one.

Re: [Nasm-devel] Does it worth to carry rdoff format?

[H. P. A. <hp...@zy...>]

On 05/09/2014 09:10 AM, Cyrill Gorcunov wrote:
> On Fri, May 09, 2014 at 08:56:27AM -0700, H. Peter Anvin wrote:
>> On 05/09/2014 12:48 AM, Cyrill Gorcunov wrote:
>>> Hi, it seems rdoff is not that popular nowadays. Maybe we should
>>> drop it off? Are there still active users?
>>
>> It is hard to say.  I suspect it is actually not the least used of the
>> formats we support... :-/
> 
> I see. OK then.
> 

We kind of have the same problem with NASM as with Linux... the only way
to really find out what is being used is to break it...!

	-hpa

Re: [Nasm-devel] Does it worth to carry rdoff format?

[Cyrill G. <gor...@gm...>]

On Fri, May 09, 2014 at 08:56:27AM -0700, H. Peter Anvin wrote:
> On 05/09/2014 12:48 AM, Cyrill Gorcunov wrote:
> > Hi, it seems rdoff is not that popular nowadays. Maybe we should
> > drop it off? Are there still active users?
> 
> It is hard to say.  I suspect it is actually not the least used of the
> formats we support... :-/

I see. OK then.

Re: [Nasm-devel] Does it worth to carry rdoff format?

[H. P. A. <hp...@zy...>]

On 05/09/2014 12:48 AM, Cyrill Gorcunov wrote:
> Hi, it seems rdoff is not that popular nowadays. Maybe we should
> drop it off? Are there still active users?
> 
> 	Cyrill

It is hard to say.  I suspect it is actually not the least used of the
formats we support... :-/

	-hpa

[Nasm-devel] Does it worth to carry rdoff format?

[Cyrill G. <gor...@gm...>]

Hi, it seems rdoff is not that popular nowadays. Maybe we should
drop it off? Are there still active users?

	Cyrill

Re: [Nasm-devel] [PATCH] changes: Document bug fixes

[H. P. A. <hp...@zy...>]

On 05/07/2014 01:58 PM, Jin Kyu Song wrote:
> - Removed an error checking code for setting evex flags
> - Fixed vector length matching bug
> 
> Signed-off-by: Jin Kyu Song <jin...@in...>

Thank you!

	-hpa

[Nasm-devel] [PATCH] changes: Document bug fixes

[Jin K. S. <jin...@in...>]

- Removed an error checking code for setting evex flags
- Fixed vector length matching bug

Signed-off-by: Jin Kyu Song <jin...@in...>
---
 doc/changes.src | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/changes.src b/doc/changes.src
index 4df068f..38cc97e 100644
--- a/doc/changes.src
+++ b/doc/changes.src
@@ -7,6 +7,17 @@
 The NASM 2 series supports x86-64, and is the production version of NASM
 since 2007.
 
+\S{cl-2.11.04} Version 2.11.04
+
+\b Removed an invalid error checking code. Sometimes a memref only with
+a displacement can also set an evex flag. For example:
+
+\c       vmovdqu32 [0xabcd]{k1}, zmm0
+
+\b Fixed a bug in disassembler that EVEX.L'L vector length was not matched
+when EVEX.b was set because it was simply considered as EVEC.RC.
+Separated EVEX.L'L case from EVEX.RC which is ignored in matching.
+
 \S{cl-2.11.03} Version 2.11.03
 
 \b Fix a bug there REX prefixes were missing on instructions inside a
-- 
1.8.3.2

Re: [Nasm-devel] [PATCH 1/2] AVX512: Remove invalid error checking

[Cyrill G. <gor...@gm...>]

On Tue, May 06, 2014 at 06:39:54PM -0700, Jin Kyu Song wrote:
> An offset-only memref can also have an opmask decorator.
> e.g.) vmovdqu32 [0xabcd]{k1}, zmm0
> 
> Signed-off-by: Jin Kyu Song <jin...@in...>

Thanks, Jin! I can't commit them by now -- lost my config
for git repo, so either you or hpa@ please.

[Nasm-devel] [PATCH 2/2] ndisasm: Match vector length with EVEX.b set

[Jin K. S. <jin...@in...>]

With broadcasting, EVEX.L'L should be matched even when EVEX.b is set.
Only in a case of embedded rounding, EVEX.L'L is ignored in matching
function since it becomes EVEX.RC.

Signed-off-by: Jin Kyu Song <jin...@in...>
---
 disasm.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/disasm.c b/disasm.c
index bb53b4c..2f68b1d 100644
--- a/disasm.c
+++ b/disasm.c
@@ -726,7 +726,9 @@ static int matches(const struct itemplate *t, uint8_t *data,
         {
             uint8_t evexm   = *r++;
             uint8_t evexwlp = *r++;
+            uint8_t modrm, valid_mask;
             ins->evex_tuple = *r++ - 0300;
+            modrm = *(origdata + 1);
 
             ins->rex |= REX_EV;
             if ((prefix->rex & (REX_EV|REX_V|REX_P)) != REX_EV)
@@ -752,9 +754,15 @@ static int matches(const struct itemplate *t, uint8_t *data,
                 break;
             }
 
-            /* If EVEX.b is set, EVEX.L'L can be rounding control bits */
-            if ((evexwlp ^ prefix->vex_lp) &
-                ((prefix->evex[2] & EVEX_P2B) ? 0x03 : 0x0f))
+            /* If EVEX.b is set with reg-reg op,
+             * EVEX.L'L contains embedded rounding control info
+             */
+            if ((prefix->evex[2] & EVEX_P2B) && ((modrm >> 6) == 3)) {
+                valid_mask = 0x3;   /* prefix only */
+            } else {
+                valid_mask = 0xf;   /* vector length and prefix */
+            }
+            if ((evexwlp ^ prefix->vex_lp) & valid_mask)
                 return false;
 
             if (c == 0250) {
-- 
1.8.3.2

[Nasm-devel] [PATCH 1/2] AVX512: Remove invalid error checking

[Jin K. S. <jin...@in...>]

An offset-only memref can also have an opmask decorator.
e.g.) vmovdqu32 [0xabcd]{k1}, zmm0

Signed-off-by: Jin Kyu Song <jin...@in...>
---
 assemble.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/assemble.c b/assemble.c
index ff92722..e9cd70f 100644
--- a/assemble.c
+++ b/assemble.c
@@ -1997,9 +1997,6 @@ static int op_evexflags(const operand * o, int mask, uint8_t byte)
 {
     int val;
 
-    if (!is_register(o->basereg))
-        errfunc(ERR_PANIC, "invalid operand passed to op_evexflags()");
-
     val = nasm_regvals[o->basereg];
 
     return evexflags(val, o->decoflags, mask, byte);
-- 
1.8.3.2

Re: [Nasm-devel] [PATCH] assemble.c: Don't drop rex prefix from instruction itself

[H. P. A. <hp...@zy...>]

On 05/04/2014 01:30 PM, Cyrill Gorcunov wrote:
> emit_rex is supposed to write REX prefix into output stream
> if needed, but we happen to drop it off on a first write
> which breaks REX required instructions if TIMES directive
> is used.

Thank you for fixing this!  We probably should do another dot release...
this is a pretty serious bug.

	-hpa

Re: [Nasm-devel] [PATCH] assemble.c: Don't drop rex prefix from instruction itself

[Cyrill G. <gor...@gm...>]

On Mon, May 05, 2014 at 10:59:23AM -0700, H. Peter Anvin wrote:
> On 05/04/2014 01:30 PM, Cyrill Gorcunov wrote:
> > emit_rex is supposed to write REX prefix into output stream
> > if needed, but we happen to drop it off on a first write
> > which breaks REX required instructions if TIMES directive
> > is used.
> 
> Thank you for fixing this!  We probably should do another dot release...
> this is a pretty serious bug.

Yeah, i think so as well. Btw, could you please merge it upstream, I've
managed to ruine my local repo with all credentials ;) I'll restore
it from backup lately.

[Nasm-devel] [PATCH] assemble.c: Don't drop rex prefix from instruction itself

[Cyrill G. <gor...@gm...>]

emit_rex is supposed to write REX prefix into output stream
if needed, but we happen to drop it off on a first write
which breaks REX required instructions if TIMES directive
is used.

For example the code like

	| times 4		movq	xmm11, xmm11

compiles into

	| 0000000000000000 <.text>:
	|   0:	f3 45 0f 7e db       	movq   %xmm11,%xmm11
	|   5:	f3 0f 7e db          	movq   %xmm3,%xmm3
	|   9:	f3 0f 7e db          	movq   %xmm3,%xmm3
	|   d:	f3 0f 7e db          	movq   %xmm3,%xmm3

instead of proper

	| 0000000000000000 <.text>:
	|   0:	f3 45 0f 7e db       	movq   %xmm11,%xmm11
	|   5:	f3 45 0f 7e db       	movq   %xmm11,%xmm11
	|   a:	f3 45 0f 7e db       	movq   %xmm11,%xmm11
	|   f:	f3 45 0f 7e db       	movq   %xmm11,%xmm11

http://bugzilla.nasm.us/show_bug.cgi?id=3392278

Reported-by: Javier <elp...@gm...>
Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---
 assemble.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/assemble.c b/assemble.c
index eeab9bb..ff92722 100644
--- a/assemble.c
+++ b/assemble.c
@@ -1366,9 +1366,8 @@ static inline unsigned int emit_rex(insn *ins, int32_t segment, int64_t offset,
 {
     if (bits == 64) {
         if ((ins->rex & REX_REAL) && !(ins->rex & (REX_V | REX_EV))) {
-            ins->rex = (ins->rex & REX_REAL) | REX_P;
-            out(offset, segment, &ins->rex, OUT_RAWDATA, 1, NO_SEG, NO_SEG);
-            ins->rex = 0;
+            int rex = (ins->rex & REX_REAL) | REX_P;
+            out(offset, segment, &rex, OUT_RAWDATA, 1, NO_SEG, NO_SEG);
             return 1;
         }
     }
-- 
1.8.3.1

Re: [Nasm-devel] [PATCH] Fix bug: AR2 treated as AR3

[Cyrill G. <gor...@gm...>]

On Fri, Feb 28, 2014 at 10:20:21PM -0800, Ben Rudiak-Gould wrote:
>    The iflags overhaul assigned AR0..AR4 to consecutive bits, but they
>    were still interpreted as consecutive integer values starting with 1.
>    As a result AR2..AR4 actually applied to arguments 3, 7, and 15
>    respectively. AR3 and AR4 are never used, so the practical upshot
>    was only that instructions like SHLD eax, ecx, byte 17 were
>    incorrectly rejected.
>    This patch fixes AR2 (in a slightly hacky way) and removes AR3 and AR4.
>    I threw AR3 and AR4 under the bus because I would rather replace all of
>    these flags with something simpler (I am working on a patch for that).
>    Signed-off-by: Ben Rudiak-Gould <ben...@gm...>

Thanks, Ben! I saw all your patches in the mailing list, they are not
missed. Will review once time permit.

[Nasm-devel] [PATCH] Remove ND from 82 aliases

[Ben Rudiak-G. <ben...@gm...>]

These exist only for the disassembler; they're useless with ND.
Maybe there should be an NA flag.

Signed-off-by: Ben Rudiak-Gould <ben...@gm...>