Nabble - The Netwide Assembler

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-07T10:31:03Z

On 12/07/2009 10:27 AM, Cyrill Gorcunov wrote:

>
> ok, that is what I managed to find.
>
> 1) Our IF_Sx masks make insns.dat position dependent. An example
> is
>
> vcvtsi2sd xmm0, xmm1, [rdi]
>
> Initially we had IF_SD here, so matches() just set DWORD and
> match the instruction fine.
>
> If (for some reason) we had a template like
>
> VCVTSI2SD xmmreg,xmmreg*,mem AVX,SANDYBRIDGE,ND,SQ
>
> placed _before_ the
>
> VCVTSI2SD xmmreg,xmmreg*,mem AVX,SANDYBRIDGE,ND,SD
>
> all compilations of
>
> vcvtsi2sd xmm0, xmm1, [rdi]
>
> would be interpreted as
>
> vcvtsi2sd xmm0, xmm1, qword [rdi]
>
> by default without any warning. I _think_ the good solution
> is to allow an user to choose which size to choose by default
> regardless of placement of this template in insns.dat.
> Something like the patch below (not for merging, just an idea).
>

No, in cases like this we should just put the SQ back on the mem64
pattern, which would label that the default. That is the remaining
proper use of the Sx flag.

There are only a small handful of patterns where default behavior is
appropriate, and they should be called out explicitly -- that's why the
Sx flags are still available.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-07T10:29:16Z

On 12/07/2009 01:56 AM, Cyrill Gorcunov wrote:
>
> I must admit this is not a good idea too. The key moment is that IF_Sx
> flags together with position in insns.dat file do work like a
> "by-default" option. So as only we switched to fuzzy logic we've broke
> this "by-default" feature (or, perhaps this is broken by design). So I
> think the best choice would be just add some "missing operand size by
> default" command line option and use it when needed. I'll cook the
> patch today evening and send for review.

Then we should identify the specific patterns which still need the Sx
flags and/or a default pattern. There should be very few of them in
legitimate code.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-07T10:27:21Z

On Sun, Dec 06, 2009 at 07:58:19PM +0300, Cyrill Gorcunov wrote:
...

>
> Perhaps, initial idea with OPTYPE_MASK is not that bad,
> the fact is one test is not enough, since parser code
> may set MEMORY_ANY we may need something like the
> change below which covers RM masks. Though we may need
> eliminate MEMORY bit itself from MEMORY_ANY. The matching
> code is a bit hard to read :) Thoughs?
>
> ---
> diff --git a/assemble.c b/assemble.c
> index 81476db..f99aee4 100644
> --- a/assemble.c
> +++ b/assemble.c
> @@ -1971,7 +1971,11 @@ static enum match_result find_match(const struct itemplate **tempp,
> */
> for (i = 0; i < temp->operands; i++) {
> if ((temp->opd[i] & SAME_AS) == 0)
> - xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
> + if (is_class(instruction->oprs[i].type & OPTYPE_MASK,
> + temp->opd[i] & OPTYPE_MASK) ||
> + is_class(instruction->oprs[i].type,
> + temp->opd[i] & MEMORY_ANY))
> + xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
> }
> opsizemissing = true;
> }

ok, that is what I managed to find.

1) Our IF_Sx masks make insns.dat position dependent. An example
is

vcvtsi2sd xmm0, xmm1, [rdi]

Initially we had IF_SD here, so matches() just set DWORD and
match the instruction fine.

If (for some reason) we had a template like

VCVTSI2SD xmmreg,xmmreg*,mem AVX,SANDYBRIDGE,ND,SQ

placed _before_ the

VCVTSI2SD xmmreg,xmmreg*,mem AVX,SANDYBRIDGE,ND,SD

all compilations of

vcvtsi2sd xmm0, xmm1, [rdi]

would be interpreted as

vcvtsi2sd xmm0, xmm1, qword [rdi]

by default without any warning. I _think_ the good solution
is to allow an user to choose which size to choose by default
regardless of placement of this template in insns.dat.
Something like the patch below (not for merging, just an idea).

-- Cyrill
---
diff --git a/assemble.c b/assemble.c
index 81476db..83df9a4 100644
--- a/assemble.c
+++ b/assemble.c
@@ -1994,9 +1994,16 @@ static enum match_result find_match(const struct itemplate **tempp,
if (is_class(REGISTER, instruction->oprs[i].type))
continue;

- /* This tests if xsizeflags[i] has more than one bit set */
- if ((xsizeflags[i] & (xsizeflags[i]-1)))
- goto done; /* No luck */
+ /*
+ * This tests if xsizeflags[i] has more than one bit set
+ * and we check if an user has supplied "by-default" argument
+ */
+ if ((xsizeflags[i] & (xsizeflags[i]-1))) {
+ int mask = get_mop_size(xsizeflags[i]);
+ if (!mask)
+ goto done;
+ xsizeflags[i] = mask;
+ }

instruction->oprs[i].type |= xsizeflags[i]; /* Set the size */
}
diff --git a/nasm.c b/nasm.c
index 28a6086..55b07d6 100644
--- a/nasm.c
+++ b/nasm.c
@@ -181,6 +181,42 @@ static bool want_usage;
static bool terminate_after_phase;
int user_nolist = 0; /* fbk 9/2/00 */

+/*
+ * missed operand size handling
+ */
+static int mop_size = 0;
+static void set_mop_size(int bits)
+{
+ switch (bits) {
+ case 8:
+ mop_size = BITS8;
+ break;
+ case 16:
+ mop_size = BITS16;
+ break;
+ case 32:
+ mop_size = BITS32;
+ break;
+ case 64:
+ mop_size = BITS64;
+ break;
+ case 80:
+ mop_size = BITS80;
+ break;
+ case 128:
+ mop_size = BITS128;
+ break;
+ case 256:
+ mop_size = BITS256;
+ break;
+ }
+}
+
+int get_mop_size(int mask)
+{
+ return (mask & mop_size) ? mop_size : 0;
+}
+
static void nasm_fputs(const char *line, FILE * outfile)
{
if (outfile) {
@@ -629,7 +665,7 @@ static bool process_arg(char *p, char *q)
return false;

if (p[0] == '-' && !stopoptions) {
- if (strchr("oOfpPdDiIlFXuUZwW", p[1])) {
+ if (strchr("moOfpPdDiIlFXuUZwW", p[1])) {
/* These parameters take values */
if (!(param = get_param(p, q, &advance)))
return advance;
@@ -747,6 +783,10 @@ static bool process_arg(char *p, char *q)
param);
break;

+ case 'm':
+ set_mop_size(atoi(param));
+ break;
+
case 'g':
using_debug_info = true;
break;
diff --git a/nasm.h b/nasm.h
index 5d5aae7..2d79afb 100644
--- a/nasm.h
+++ b/nasm.h
@@ -890,4 +890,6 @@ extern const char nasm_compile_options[];
extern const char nasm_comment[];
extern const char nasm_signature[];

+int get_mop_size(int mask);
+
#endif

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-07T01:56:40Z

On Sun, Dec 6, 2009 at 7:58 PM, Cyrill Gorcunov <gorcunov@...> wrote:

> On Thu, Dec 03, 2009 at 06:08:38PM +0300, Cyrill Gorcunov wrote:
>> On Thu, Dec 03, 2009 at 06:51:38AM -0800, H. Peter Anvin wrote:
>> > On 12/03/2009 06:46 AM, Cyrill Gorcunov wrote:
>> > >
>> > > As I see you didn't applied it to the master repo. And
>> > > please do NOT. It breaks some code. I'll post other
>> > > propose/patch later (which fixed the problem but need
>> > > a deep review).
>> > >
>> >
>> > Thanks for the warning!
>> >
>> > -hpa
>> >
>>
>> Peter, if only I don't miss something I guess we need
>> the patch below. The type of operands in template and
>> instruction (being compiled) is checked in matches() and
>> we've "missed operand size" only for those operands
>> which other characteristics do match with template and
>> only size is different. But sometime we have _several_ templates
>> which have only difference in BITSx mask. So as only
>> we get cumulative mask we take "minimal" BITSx from there
>> and start matches() again.
>>
>> -- Cyrill
>> ---
>> From fb773763d8cdcca0ba01ab7707d73231a88fcab1 Mon Sep 17 00:00:00 2001
>> From: Cyrill Gorcunov <gorcunov@...>
>> Date: Thu, 3 Dec 2009 18:02:55 +0300
>> Subject: [PATCH] find_match: find out minimal size match in fuzzy logic algo
>>
>> In case if several instruction templates match
>> our instruction with difference in size of the
>> operand (and as result it's unclear which template
>> is "better" for us) we just choose one which is
>> smaller.
>>
>> An user always may choose preferred by explicitly pointing
>> out the operand size.
>>
>> Signed-off-by: Cyrill Gorcunov <gorcunov@...>
>> ---
>> assemble.c | 27 ++++++++++++++++++++++++---
>> 1 files changed, 24 insertions(+), 3 deletions(-)
>>
> ...
>
> Perhaps, initial idea with OPTYPE_MASK is not that bad,
> the fact is one test is not enough, since parser code
> may set MEMORY_ANY we may need something like the
> change below which covers RM masks. Though we may need
> eliminate MEMORY bit itself from MEMORY_ANY. The matching
> code is a bit hard to read :) Thoughs?
>
> ---
> diff --git a/assemble.c b/assemble.c
> index 81476db..f99aee4 100644
> --- a/assemble.c
> +++ b/assemble.c
> @@ -1971,7 +1971,11 @@ static enum match_result find_match(const struct itemplate **tempp,
> */
> for (i = 0; i < temp->operands; i++) {
> if ((temp->opd[i] & SAME_AS) == 0)
> - xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
> + if (is_class(instruction->oprs[i].type & OPTYPE_MASK,
> + temp->opd[i] & OPTYPE_MASK) ||
> + is_class(instruction->oprs[i].type,
> + temp->opd[i] & MEMORY_ANY))
> + xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
> }
> opsizemissing = true;
> }
>

I must admit this is not a good idea too. The key moment is that IF_Sx
flags together with position in insns.dat file do work like a
"by-default" option. So as only we switched to fuzzy logic we've broke
this "by-default" feature (or, perhaps this is broken by design). So I
think the best choice would be just add some "missing operand size by
default" command line option and use it when needed. I'll cook the
patch today evening and send for review.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-06T08:58:19Z

On Thu, Dec 03, 2009 at 06:08:38PM +0300, Cyrill Gorcunov wrote:

> On Thu, Dec 03, 2009 at 06:51:38AM -0800, H. Peter Anvin wrote:
> > On 12/03/2009 06:46 AM, Cyrill Gorcunov wrote:
> > >
> > > As I see you didn't applied it to the master repo. And
> > > please do NOT. It breaks some code. I'll post other
> > > propose/patch later (which fixed the problem but need
> > > a deep review).
> > >
> >
> > Thanks for the warning!
> >
> > -hpa
> >
>
> Peter, if only I don't miss something I guess we need
> the patch below. The type of operands in template and
> instruction (being compiled) is checked in matches() and
> we've "missed operand size" only for those operands
> which other characteristics do match with template and
> only size is different. But sometime we have _several_ templates
> which have only difference in BITSx mask. So as only
> we get cumulative mask we take "minimal" BITSx from there
> and start matches() again.
>
> -- Cyrill
> ---
> From fb773763d8cdcca0ba01ab7707d73231a88fcab1 Mon Sep 17 00:00:00 2001
> From: Cyrill Gorcunov <gorcunov@...>
> Date: Thu, 3 Dec 2009 18:02:55 +0300
> Subject: [PATCH] find_match: find out minimal size match in fuzzy logic algo
>
> In case if several instruction templates match
> our instruction with difference in size of the
> operand (and as result it's unclear which template
> is "better" for us) we just choose one which is
> smaller.
>
> An user always may choose preferred by explicitly pointing
> out the operand size.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@...>
> ---
> assemble.c | 27 ++++++++++++++++++++++++---
> 1 files changed, 24 insertions(+), 3 deletions(-)
>

...

Perhaps, initial idea with OPTYPE_MASK is not that bad,
the fact is one test is not enough, since parser code
may set MEMORY_ANY we may need something like the
change below which covers RM masks. Though we may need
eliminate MEMORY bit itself from MEMORY_ANY. The matching
code is a bit hard to read :) Thoughs?

---
diff --git a/assemble.c b/assemble.c
index 81476db..f99aee4 100644
--- a/assemble.c
+++ b/assemble.c
@@ -1971,7 +1971,11 @@ static enum match_result find_match(const struct itemplate **tempp,
*/
for (i = 0; i < temp->operands; i++) {
if ((temp->opd[i] & SAME_AS) == 0)
- xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
+ if (is_class(instruction->oprs[i].type & OPTYPE_MASK,
+ temp->opd[i] & OPTYPE_MASK) ||
+ is_class(instruction->oprs[i].type,
+ temp->opd[i] & MEMORY_ANY))
+ xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
}
opsizemissing = true;
}

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

[ nasm-Bugs-2887108 ] imul reg,reg,imm32 defective

2009-12-05T03:24:31Z

Bugs item #2887108, was opened at 2009-10-27 15:02
Message generated for change (Settings changed) made by cyrillos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2887108&group_id=6208

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Assembler
Group: None
>Status: Closed
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Jasper Neumann (jasper_neumann)
Assigned to: Nobody/Anonymous (nobody)
Summary: imul reg,reg,imm32 defective

Initial Comment:
Commands like
imul eax,eax,0x12340001
produce wrong code (imul reg,reg,imm8). It seems that the upper 16 bits are not analyzed for op code selection.

Sample, all imul produce wrong code; b.asm:
===
bits 32
global test
test:
imul eax,eax,65537
imul eax,eax,0x00010001
imul eax,eax,0x1234007f
imul eax,eax,0xfedcff80
ret
===

Command line: nasm -Ox -t -f rdf -o b.rdf b.asm

BTW: The variant "imul reg,mem,const" is OK.

This applies to at least the versions 2.08rc1 and 2.07.

----------------------------------------------------------------------

Comment By: Jasper Neumann (jasper_neumann)
Date: 2009-11-12 16:09

Message:
I think it might be sensible to add some new test cases to test\imul.asm in
order to test for the kind of bug described above.
Possibly similar tests for other commands should be added as well.

----------------------------------------------------------------------

Comment By: H. Peter Anvin (hpa)
Date: 2009-11-03 20:29

Message:
This item has been resolved; the fix has been checked into git
(http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at http://www.nasm.us/; the
snapshot robot usually runs some time between 07:00 and 09:00 UTC, but
sometimes runs immediately if there was no previous snapshot for today.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-01 10:40

Message:
Unfortunately it was not correct. I've reverted the commit. Will inform as
only issue get fixed.

----------------------------------------------------------------------

Comment By: Cyrill Gorcunov (cyrillos)
Date: 2009-10-31 10:40

Message:
Pushed out as commit 41208028ff52d190044ee7532bf14c5aca0f899a. The fix will
be in 2.08 release.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-10-31 10:26

Message:
Will push patch into main repo soon

----------------------------------------------------------------------

Comment By: Cyrill Gorcunov (cyrillos)
Date: 2009-10-31 01:30

Message:
Patch just has been sent for review. Thanks again for report!

----------------------------------------------------------------------

Comment By: Cyrill Gorcunov (cyrillos)
Date: 2009-10-30 19:47

Message:
Hmm, this is due to -Ox, investigating.... Thanks!

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2887108&group_id=6208

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-bugs mailing list
Nasm-bugs@...
https://lists.sourceforge.net/lists/listinfo/nasm-bugs

From forum: nasm-bugs

[ nasm-Bugs-2907058 ] minor handle leak in assemble.c

2009-12-05T03:15:39Z

Bugs item #2907058, was opened at 2009-12-01 22:01
Message generated for change (Settings changed) made by cyrillos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2907058&group_id=6208

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Assembler
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor handle leak in assemble.c

Initial Comment:
In nasm 2.07, cppcheck notes the following leak

Checking assemble.c...
[assemble.c:736]: (error) Resource leak: fp

----------------------------------------------------------------------

Comment By: Cyrill Gorcunov (cyrillos)
Date: 2009-12-05 14:15

Message:
This item has been resolved; the fix has been checked into git
(http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at http://www.nasm.us/; the
snapshot robot usually runs some time between 07:00 and 09:00 UTC, but
sometimes runs immediately if there was no previous snapshot for today.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2907058&group_id=6208

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-bugs mailing list
Nasm-bugs@...
https://lists.sourceforge.net/lists/listinfo/nasm-bugs

From forum: nasm-bugs

[ nasm-Bugs-2907058 ] minor handle leak in assemble.c

2009-12-05T03:15:11Z

Bugs item #2907058, was opened at 2009-12-01 22:01
Message generated for change (Comment added) made by cyrillos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2907058&group_id=6208

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Assembler
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor handle leak in assemble.c

Initial Comment:
In nasm 2.07, cppcheck notes the following leak

Checking assemble.c...
[assemble.c:736]: (error) Resource leak: fp

----------------------------------------------------------------------

Comment By: Cyrill Gorcunov (cyrillos)
Date: 2009-12-05 14:15

Message:
This item has been resolved; the fix has been checked into git
(http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at http://www.nasm.us/; the
snapshot robot usually runs some time between 07:00 and 09:00 UTC, but
sometimes runs immediately if there was no previous snapshot for today.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2907058&group_id=6208

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-bugs mailing list
Nasm-bugs@...
https://lists.sourceforge.net/lists/listinfo/nasm-bugs

From forum: nasm-bugs

Re: [PATCH] tests: remove golden directory at cleaning

2009-12-03T20:04:38Z

On 12/4/09, H. Peter Anvin <hpa@...> wrote:

> On 12/03/2009 12:58 PM, Cyrill Gorcunov wrote:
>> Don't forget to delete test/golden directory
>> if "clean" passed.
>>
>> Signed-off-by: Cyrill Gorcunov <gorcunov@...>
>> ---
>> test/Makefile | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/test/Makefile b/test/Makefile
>> index 8b51359..100f1cc 100644
>> --- a/test/Makefile
>> +++ b/test/Makefile
>> @@ -59,6 +59,7 @@ clean:
>> rm -f *.com *.o *.o64 *.obj *.win32 *.win64 *.exe *.lst *.bin
>> rm -f *.dbg *.coff *.ith *.srec *.mo32 *.mo64
>> rm -rf testresults
>> + rm -rf golden
>> rm -f elftest elftest64
>>
>> spotless: clean
>
> We should absolutely not do this! Typically golden comes from a
> previous build that we are trying to compare with.
>
> -hpa
>
>

Ah, i see. Thanks for explanation!

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: [PATCH] tests: remove golden directory at cleaning

2009-12-03T14:53:05Z

On 12/03/2009 12:58 PM, Cyrill Gorcunov wrote:

> Don't forget to delete test/golden directory
> if "clean" passed.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@...>
> ---
> test/Makefile | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/test/Makefile b/test/Makefile
> index 8b51359..100f1cc 100644
> --- a/test/Makefile
> +++ b/test/Makefile
> @@ -59,6 +59,7 @@ clean:
> rm -f *.com *.o *.o64 *.obj *.win32 *.win64 *.exe *.lst *.bin
> rm -f *.dbg *.coff *.ith *.srec *.mo32 *.mo64
> rm -rf testresults
> + rm -rf golden
> rm -f elftest elftest64
>
> spotless: clean

We should absolutely not do this! Typically golden comes from a
previous build that we are trying to compare with.

-hpa

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

[PATCH] tests: remove golden directory at cleaning

2009-12-03T12:58:56Z

Don't forget to delete test/golden directory
if "clean" passed.

Signed-off-by: Cyrill Gorcunov <gorcunov@...>
---
test/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/test/Makefile b/test/Makefile
index 8b51359..100f1cc 100644
--- a/test/Makefile
+++ b/test/Makefile
@@ -59,6 +59,7 @@ clean:
rm -f *.com *.o *.o64 *.obj *.win32 *.win64 *.exe *.lst *.bin
rm -f *.dbg *.coff *.ith *.srec *.mo32 *.mo64
rm -rf testresults
+ rm -rf golden
rm -f elftest elftest64

spotless: clean
--
1.6.5

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-03T07:08:38Z

On Thu, Dec 03, 2009 at 06:51:38AM -0800, H. Peter Anvin wrote:

> On 12/03/2009 06:46 AM, Cyrill Gorcunov wrote:
> >
> > As I see you didn't applied it to the master repo. And
> > please do NOT. It breaks some code. I'll post other
> > propose/patch later (which fixed the problem but need
> > a deep review).
> >
>
> Thanks for the warning!
>
> -hpa
>

Peter, if only I don't miss something I guess we need
the patch below. The type of operands in template and
instruction (being compiled) is checked in matches() and
we've "missed operand size" only for those operands
which other characteristics do match with template and
only size is different. But sometime we have _several_ templates
which have only difference in BITSx mask. So as only
we get cumulative mask we take "minimal" BITSx from there
and start matches() again.

-- Cyrill
---
>From fb773763d8cdcca0ba01ab7707d73231a88fcab1 Mon Sep 17 00:00:00 2001
From: Cyrill Gorcunov <gorcunov@...>
Date: Thu, 3 Dec 2009 18:02:55 +0300
Subject: [PATCH] find_match: find out minimal size match in fuzzy logic algo

In case if several instruction templates match
our instruction with difference in size of the
operand (and as result it's unclear which template
is "better" for us) we just choose one which is
smaller.

An user always may choose preferred by explicitly pointing
out the operand size.

Signed-off-by: Cyrill Gorcunov <gorcunov@...>
---
assemble.c | 27 ++++++++++++++++++++++++---
1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/assemble.c b/assemble.c
index 4af059b..7372cbf 100644
--- a/assemble.c
+++ b/assemble.c
@@ -1992,9 +1992,30 @@ static enum match_result find_match(const struct itemplate **tempp,
if (is_class(REGISTER, instruction->oprs[i].type))
continue;

- /* This tests if xsizeflags[i] has more than one bit set */
- if ((xsizeflags[i] & (xsizeflags[i]-1)))
- goto done; /* No luck */
+ /*
+ * This tests if xsizeflags[i] has more than one bit set
+ * which means there is are few templates match our instruction
+ * with difference in size of operand, so we choose a
+ * "minimal" one
+ */
+ if ((xsizeflags[i] & (xsizeflags[i] - 1))) {
+ if (xsizeflags[i] & BITS8)
+ xsizeflags[i] = BITS8;
+ else if (xsizeflags[i] & BITS16)
+ xsizeflags[i] = BITS16;
+ else if (xsizeflags[i] & BITS32)
+ xsizeflags[i] = BITS32;
+ else if (xsizeflags[i] & BITS64)
+ xsizeflags[i] = BITS64;
+ else if (xsizeflags[i] & BITS80)
+ xsizeflags[i] = BITS80;
+ else if (xsizeflags[i] & BITS128)
+ xsizeflags[i] = BITS128;
+ else if (xsizeflags[i] & BITS256)
+ xsizeflags[i] = BITS256;
+ else
+ goto done; /* No luck */
+ }

instruction->oprs[i].type |= xsizeflags[i]; /* Set the size */
}
--
1.6.5

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-03T06:51:38Z

On 12/03/2009 06:46 AM, Cyrill Gorcunov wrote:
>
> As I see you didn't applied it to the master repo. And
> please do NOT. It breaks some code. I'll post other
> propose/patch later (which fixed the problem but need
> a deep review).
>

Thanks for the warning!

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-03T06:46:53Z

On Wed, Dec 02, 2009 at 04:47:24PM -0800, H. Peter Anvin wrote:

> On 12/02/2009 01:34 PM, Cyrill Gorcunov wrote:
> >
> > Ok, Peter, here is a final version of what I've done. Please review.
> >
>
> I have applied it, even though I don't think it's technically 100%
> correct. However, it shouldn't introduce any new failures, and so it is
> better than what we have now.
>
> The real criterion should be "would this have worked if we had had a
> size argument." This is a hard one to answer without further
> restructuring the code, though.
>
> -hpa
>

As I see you didn't applied it to the master repo. And
please do NOT. It breaks some code. I'll post other
propose/patch later (which fixed the problem but need
a deep review).

-- Cyrill

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-02T22:21:20Z

On 12/3/09, H. Peter Anvin <hpa@...> wrote:

> On 12/02/2009 01:34 PM, Cyrill Gorcunov wrote:
>>
>> Ok, Peter, here is a final version of what I've done. Please review.
>>
>
> I have applied it, even though I don't think it's technically 100%
> correct. However, it shouldn't introduce any new failures, and so it is
> better than what we have now.
>
> The real criterion should be "would this have worked if we had had a
> size argument." This is a hard one to answer without further
> restructuring the code, though.
>
> -hpa
>
> --

Doh, now it breaks if RM_XMM in template and MEMORY in instruction :(

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-02T16:47:24Z

On 12/02/2009 01:34 PM, Cyrill Gorcunov wrote:
>
> Ok, Peter, here is a final version of what I've done. Please review.
>

I have applied it, even though I don't think it's technically 100%
correct. However, it shouldn't introduce any new failures, and so it is
better than what we have now.

The real criterion should be "would this have worked if we had had a
size argument." This is a hard one to answer without further
restructuring the code, though.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: vcvtsi2sd broken in conversion to explicit operand size

2009-12-02T13:34:28Z

On Wed, Dec 02, 2009 at 12:56:57PM -0800, H. Peter Anvin wrote:

> On 12/02/2009 12:36 PM, Cyrill Gorcunov wrote:
> >
> > Peter, I suppose we need something like
> >
> > /*
> > * Missing operand size and a candidate for fuzzy matching...
> > */
> > for (i = 0; i < temp->operands; i++) {
> > if ((temp->opd[i] & SAME_AS) == 0)
> > if (is_class(instruction->oprs[i].type & OPTYPE_MASK, temp->opd[i]))
> > xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
> > }
> > opsizemissing = true;
> >
> > Ie set size _only_ if it was same class operand in template and instruction. No?
> >
>
> Yes, something like that... although it probably should be & ~SIZE_MASK
> instead of OPTYPE_MASK -- "would these actually match if it wasn't for
> the size"?
>
> -hpa
>

Ok, Peter, here is a final version of what I've done. Please review.

Preamble for nasm-devel:

Viktor reported that after commit

| commit b2cad279d9af14fd054602fe067bf20488199ec4
| Author: Cyrill Gorcunov <gorcunov@...>
| Date: Fri Aug 7 00:26:54 2009 +0400
|
| insns.dat -- convert AVX instructions part1
|
| Convert Intel AVX instructions to explisit size
| format. Part 1.
|
| Also SAR instruction is touched as well.
|
| Signed-off-by: Cyrill Gorcunov <gorcunov@...>

nasm stop compiling compatibility instructions like

vcvtsi2sd xmm0, xmm1, [rdi] ; Compatibility

this is due to some obscure moments of fuzzy logic technique
used to find out which size of operand we may use. In this
example it should be DWORD in memory -- ie MEMORY|BITS32 in
template.

So the patch for review is here. It seems we should use SIZE_MASK
instead. But I didn't find proper combinaion.

-- Cyrill
---
>From 24340509a8cd862aa8379ec35e30b570c8e83a03 Mon Sep 17 00:00:00 2001
From: Cyrill Gorcunov <gorcunov@...>
Date: Thu, 3 Dec 2009 00:20:33 +0300
Subject: [PATCH 2/2] find_match: set argument size only for same class operands

We should check if operand in template has the same
class as operand in instruction to eliminate an ability
to set cumulative mask from different classes of operands.

Reported-by: Victor van den Elzen <victor.vde@...>
Signed-off-by: Cyrill Gorcunov <gorcunov@...>
---
assemble.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/assemble.c b/assemble.c
index 4af059b..220ff08 100644
--- a/assemble.c
+++ b/assemble.c
@@ -1968,8 +1968,10 @@ static enum match_result find_match(const struct itemplate **tempp,
* Missing operand size and a candidate for fuzzy matching...
*/
for (i = 0; i < temp->operands; i++) {
- if ((temp->opd[i] & SAME_AS) == 0)
- xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
+ if ((temp->opd[i] & SAME_AS) == 0 &&
+ (is_class(instruction->oprs[i].type & OPTYPE_MASK,
+ temp->opd[i] & OPTYPE_MASK)))
+ xsizeflags[i] |= temp->opd[i] & SIZE_MASK;
}
opsizemissing = true;
}
--
1.6.5

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

[ nasm-Bugs-2907058 ] minor handle leak in assemble.c

2009-12-01T11:01:40Z

Bugs item #2907058, was opened at 2009-12-01 19:01
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2907058&group_id=6208

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Assembler
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor handle leak in assemble.c

Initial Comment:
In nasm 2.07, cppcheck notes the following leak

Checking assemble.c...
[assemble.c:736]: (error) Resource leak: fp

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2907058&group_id=6208

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-bugs mailing list
Nasm-bugs@...
https://lists.sourceforge.net/lists/listinfo/nasm-bugs

From forum: nasm-bugs

Re: MachO: Use nasm_error by default

2009-11-30T12:52:20Z

H. Peter Anvin wrote:
> On 11/30/2009 12:02 PM, Cyrill Gorcunov wrote:
>> If I recall correctly someone on forum was asking for RDF standart.
>> Perhaps it's still used.
>>
>
> Well, outrdf.c as opposed to outrdf2.c...

Yeah. As I recall, we evicted the old outrdf.c from the tree, and it
slipped back in somehow. Deb Wiles was concerned about "dropping" a
format, but I think we convinced her that the guys who were using rdf
v.1 were the ones who abandoned it and went to rdf v.2. I agree that it
should be removed.

Best,
Frank

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: MachO: Use nasm_error by default

2009-11-30T12:15:38Z

On 11/30/2009 12:02 PM, Cyrill Gorcunov wrote:
>
> If I recall correctly someone on forum was asking for RDF standart.
> Perhaps it's still used.
>

Well, outrdf.c as opposed to outrdf2.c...

-hpa

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: MachO: Use nasm_error by default

2009-11-30T12:02:19Z

On Mon, Nov 30, 2009 at 11:50:56AM -0800, H. Peter Anvin wrote:
> On 11/30/2009 11:40 AM, Cyrill Gorcunov wrote:
> >
> > Just noted you've already made so.
> >
> > -- Cyrill
> >
>
> Yes... I'm still confused how it manage to escape.

Have no idea, just hit it while was fixing the bug
with binding symbols to .text section (other patch
was posted). And then I found a limit of section
name (up to 8 symbols) in MachO, so I decided to try
to compile horrible asm file -- and eventually got
Segmentation Fault. This was a surprise since all
code looks pretty fine.

>
> outrdf.c still seems to use the old interfaces; I'm not sure if there is
> any reason to keep outrdf.c alive since I doubt it has even compiled any
> time recently...
>
> -hpa
>

If I recall correctly someone on forum was asking for RDF standart.
Perhaps it's still used.

-- Cyrill

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: MachO: Use nasm_error by default

2009-11-30T11:50:56Z

On 11/30/2009 11:40 AM, Cyrill Gorcunov wrote:
>
> Just noted you've already made so.
>
> -- Cyrill
>

Yes... I'm still confused how it manage to escape.

outrdf.c still seems to use the old interfaces; I'm not sure if there is
any reason to keep outrdf.c alive since I doubt it has even compiled any
time recently...

-hpa

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: MachO: Use nasm_error by default

2009-11-30T11:40:34Z

On Mon, Nov 30, 2009 at 10:39:28PM +0300, Cyrill Gorcunov wrote:

> On Mon, Nov 30, 2009 at 11:26:43AM -0800, H. Peter Anvin wrote:
> > On 11/29/2009 11:55 AM, Cyrill Gorcunov wrote:
> > > On Sun, Nov 29, 2009 at 10:35:50PM +0300, Cyrill Gorcunov wrote:
> > >> Please review, I've just got NULL dereference.
> > >> I dunno perhaps it's just Linux environment
> > >> specifics but error here is static variable never
> > >> being explicitly set other then 0.
> > >>
> > >> MachO-64 uses nasm_error by default so it handles
> > >> error messages without problems.
> > >>
> > >> Patch looks good?
> > >
> > > Sorry for previous message Subject: line :(
> > >
> > >>
> >
> > Humm... it looks like several files escaped the global replacement of
> > functions... this is probably a source of bugs so I'd rather fix it
> > properly. In the case of outmacho32.c it means changing error() to
> > nasm_error().
> >
> > -hpa
> >
>
> Yes, initially I would like to make it so, but then though to not
> bring a number of line changed in late -rc. If this is acceptible,
> I may change them and commit. WHat is preferred?
>
> -- Cyrill

Just noted you've already made so.

-- Cyrill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: MachO: Use nasm_error by default

2009-11-30T11:39:28Z

On Mon, Nov 30, 2009 at 11:26:43AM -0800, H. Peter Anvin wrote:

> On 11/29/2009 11:55 AM, Cyrill Gorcunov wrote:
> > On Sun, Nov 29, 2009 at 10:35:50PM +0300, Cyrill Gorcunov wrote:
> >> Please review, I've just got NULL dereference.
> >> I dunno perhaps it's just Linux environment
> >> specifics but error here is static variable never
> >> being explicitly set other then 0.
> >>
> >> MachO-64 uses nasm_error by default so it handles
> >> error messages without problems.
> >>
> >> Patch looks good?
> >
> > Sorry for previous message Subject: line :(
> >
> >>
>
> Humm... it looks like several files escaped the global replacement of
> functions... this is probably a source of bugs so I'd rather fix it
> properly. In the case of outmacho32.c it means changing error() to
> nasm_error().
>
> -hpa
>

Yes, initially I would like to make it so, but then though to not
bring a number of line changed in late -rc. If this is acceptible,
I may change them and commit. WHat is preferred?

-- Cyrill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: MachO: Use nasm_error by default

2009-11-30T11:26:43Z

On 11/29/2009 11:55 AM, Cyrill Gorcunov wrote:

> On Sun, Nov 29, 2009 at 10:35:50PM +0300, Cyrill Gorcunov wrote:
>> Please review, I've just got NULL dereference.
>> I dunno perhaps it's just Linux environment
>> specifics but error here is static variable never
>> being explicitly set other then 0.
>>
>> MachO-64 uses nasm_error by default so it handles
>> error messages without problems.
>>
>> Patch looks good?
>
> Sorry for previous message Subject: line :(
>
>>

Humm... it looks like several files escaped the global replacement of
functions... this is probably a source of bugs so I'd rather fix it
properly. In the case of outmacho32.c it means changing error() to
nasm_error().

-hpa

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

[ nasm-Bugs-2835192 ] Not defaulting to .text

2009-11-29T13:57:22Z

Bugs item #2835192, was opened at 2009-08-11 02:00
Message generated for change (Comment added) made by cyrillos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2835192&group_id=6208

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Assembler
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Armence (armence)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not defaulting to .text

Initial Comment:
When this file is assembled with the following options: -felf32 the start symbol is undefined as illustrated in the following obdump of the resulting output:
00000000 l df *ABS* 00000000 start.s
00000000 l d .bss 00000000 .bss
00000000 l d .text 00000000 .text
00000001 l *ABS* 00000000 MULTIBOOT_PAGE_ALIGN
00000002 l *ABS* 00000000 MULTIBOOT_MEMORY_INFO
00010000 l *ABS* 00000000 MULTIBOOT_AOUT_KLUDGE
1badb002 l *ABS* 00000000 MULTIBOOT_HEADER_MAGIC
00010003 l *ABS* 00000000 MULTIBOOT_HEADER_FLAGS
e4514ffb l *ABS* 00000000 MULTIBOOT_CHECKSUM
00000000 l *UND* 00000000 mboot
00000000 l *UND* 00000000 stublet
00002000 l .bss 00000000 _sys_stack
00000000 *UND* 00000000 code
00000000 *UND* 00000000 bss
00000000 *UND* 00000000 end
00000000 *UND* 00000000 start

Uncommenting SECTION .text solves the problem

----------------------------------------------------------------------

Comment By: Cyrill Gorcunov (cyrillos)
Date: 2009-11-30 00:57

Message:
Thanks for report. I've just posted a patch for review.

----------------------------------------------------------------------

Comment By: Armence (armence)
Date: 2009-08-11 02:02

Message:
I forgot to put version info. Here it is:
NASM version 2.05.01 compiled on Nov 5 2008

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2835192&group_id=6208

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-bugs mailing list
Nasm-bugs@...
https://lists.sourceforge.net/lists/listinfo/nasm-bugs

From forum: nasm-bugs

[PATCH] Elf: bind labels to text section by default

2009-11-29T12:24:08Z

Please review. The former request is there

http://sourceforge.net/tracker/?func=detail&aid=2835192&group_id=6208&atid=106208

-- Cyrill
---
From: Cyrill Gorcunov <gorcunov@...>
Date: Sun, 29 Nov 2009 23:21:16 +0300
Subject: [PATCH] Elf: bind labels to text section by default

In case if SECTION is omitted for pure code we form
it by default and put it there. In turn labels are
not handled the same manner.

So lets bind them to text section by default as well.

[ BR: 2835192 ]

Signed-off-by: Cyrill Gorcunov <gorcunov@...>
---
output/outelf32.c | 23 ++++++++++++-----------
output/outelf64.c | 23 ++++++++++++-----------
2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/output/outelf32.c b/output/outelf32.c
index de31805..1625fb7 100644
--- a/output/outelf32.c
+++ b/output/outelf32.c
@@ -523,19 +523,20 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
else {
int i;
sym->section = SHN_UNDEF;
- if (nsects == 0 && segment == def_seg) {
+ if (segment == def_seg) {
+ /* we have to be sure at least text section is there */
int tempint;
- if (segment != elf_section_names(".text", 2, &tempint))
- nasm_error(ERR_PANIC,
- "strange segment conditions in ELF driver");
- sym->section = nsects;
- } else {
- for (i = 0; i < nsects; i++)
- if (segment == sects[i]->index) {
- sym->section = i + 1;
- break;
- }
+ elf_section_names(".text", 2, &tempint);
}
+ sym->section = nsects;
+ for (i = 0; i < nsects; i++) {
+ if (segment == sects[i]->index) {
+ sym->section = i + 1;
+ break;
+ }
+ }
+ if (nsects && i == nsects)
+ nasm_error(ERR_PANIC, "strange segment conditions in ELF driver");
}

if (is_global == 2) {
diff --git a/output/outelf64.c b/output/outelf64.c
index ba049b1..18508fb 100644
--- a/output/outelf64.c
+++ b/output/outelf64.c
@@ -527,19 +527,20 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
else {
int i;
sym->section = SHN_UNDEF;
- if (nsects == 0 && segment == def_seg) {
+ if (segment == def_seg) {
+ /* we have to be sure at least text section is there */
int tempint;
- if (segment != elf_section_names(".text", 2, &tempint))
- nasm_error(ERR_PANIC,
- "strange segment conditions in ELF driver");
- sym->section = nsects;
- } else {
- for (i = 0; i < nsects; i++)
- if (segment == sects[i]->index) {
- sym->section = i + 1;
- break;
- }
+ elf_section_names(".text", 2, &tempint);
}
+ sym->section = nsects;
+ for (i = 0; i < nsects; i++) {
+ if (segment == sects[i]->index) {
+ sym->section = i + 1;
+ break;
+ }
+ }
+ if (nsects && i == nsects)
+ nasm_error(ERR_PANIC, "strange segment conditions in ELF driver");
}

if (is_global == 2) {
--
1.6.5

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

MachO: Use nasm_error by default

2009-11-29T11:55:28Z

On Sun, Nov 29, 2009 at 10:35:50PM +0300, Cyrill Gorcunov wrote:
> Please review, I've just got NULL dereference.
> I dunno perhaps it's just Linux environment
> specifics but error here is static variable never
> being explicitly set other then 0.
>
> MachO-64 uses nasm_error by default so it handles
> error messages without problems.
>
> Patch looks good?

Sorry for previous message Subject: line :(

>
> -- Cyrill
> ---
> From: Cyrill Gorcunov <gorcunov@...>
> Date: Sun, 29 Nov 2009 22:27:06 +0300
> Subject: [PATCH] MachO: Use nasm_error by default
>
> We may reach strange errors like NULL dereference
> while reporting error. So make explicit assignment
> the error function to nasm_error.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@...>
> ---
> output/outmacho32.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/output/outmacho32.c b/output/outmacho32.c
> index 4ce9eea..99e0e94 100644
> --- a/output/outmacho32.c
> +++ b/output/outmacho32.c
> @@ -208,7 +208,7 @@ static struct RAA *extsyms;
> static struct SAA *strs;
> static uint32_t strslen;
>
> -static efunc error;
> +static efunc error = nasm_error;
>
> extern struct ofmt of_macho;
>
> --
> 1.6.5
>

-- Cyrill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

asd

2009-11-29T11:35:50Z

Please review, I've just got NULL dereference.
I dunno perhaps it's just Linux environment
specifics but error here is static variable never
being explicitly set other then 0.

MachO-64 uses nasm_error by default so it handles
error messages without problems.

Patch looks good?

-- Cyrill
---
From: Cyrill Gorcunov <gorcunov@...>
Date: Sun, 29 Nov 2009 22:27:06 +0300
Subject: [PATCH] MachO: Use nasm_error by default

We may reach strange errors like NULL dereference
while reporting error. So make explicit assignment
the error function to nasm_error.

Signed-off-by: Cyrill Gorcunov <gorcunov@...>
---
output/outmacho32.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/output/outmacho32.c b/output/outmacho32.c
index 4ce9eea..99e0e94 100644
--- a/output/outmacho32.c
+++ b/output/outmacho32.c
@@ -208,7 +208,7 @@ static struct RAA *extsyms;
static struct SAA *strs;
static uint32_t strslen;

-static efunc error;
+static efunc error = nasm_error;

extern struct ofmt of_macho;

--
1.6.5

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: 2.08rc5; final release?

2009-11-29T10:31:09Z

Cyrill Gorcunov wrote:

On Sat, Nov 28, 2009 at 03:36:48PM -0800, H. Peter Anvin wrote:

I just tagged 2.08rc5; does anyone see anything (other than the release
notes) that still need to happen before 2.08, or should we say it's good
enough?
	
	-hpa


Looks good enough for me. Though we still have a few pending
issues

1) context-local macros still defined in new context - ID: 2899470
   http://sourceforge.net/tracker/?func=detail&aid=2899470&group_id=6208&atid=106208
   Keith, could you take a look?

2) Not defaulting to .text - ID: 2835192
   http://sourceforge.net/tracker/?func=detail&aid=2835192&group_id=6208&atid=106208
   Will take a look.

To be honest, I won't have the time to look at it for at least the next two weeks.

-Keith
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: 2.08rc5; final release?

2009-11-29T01:58:30Z

On Sat, Nov 28, 2009 at 03:36:48PM -0800, H. Peter Anvin wrote:
> I just tagged 2.08rc5; does anyone see anything (other than the release
> notes) that still need to happen before 2.08, or should we say it's good
> enough?
>
> -hpa
>

Looks good enough for me. Though we still have a few pending
issues

1) context-local macros still defined in new context - ID: 2899470
http://sourceforge.net/tracker/?func=detail&aid=2899470&group_id=6208&atid=106208
Keith, could you take a look?

2) Not defaulting to .text - ID: 2835192
http://sourceforge.net/tracker/?func=detail&aid=2835192&group_id=6208&atid=106208
Will take a look.

-- Cyrill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

2.08rc5; final release?

2009-11-28T15:36:48Z

I just tagged 2.08rc5; does anyone see anything (other than the release
notes) that still need to happen before 2.08, or should we say it's good
enough?

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: preprocessor hang?

2009-11-21T00:12:04Z

On Fri, Nov 20, 2009 at 11:52:23PM -0600, Keith Kanios wrote:

> Keith Kanios wrote:
>> Cyrill Gorcunov wrote:
>>
>>> On Wed, Nov 18, 2009 at 12:48:46PM -0800, anonymous coward wrote:
>>>
>>>>>> I suppose we may need Keith to take a look on. CC'ed.
>>>>>>
>>>>> Keith, it seems [...]
>>>>>
>>>> Btw, after you manage to fix this recursion problem, the code
>>>> in question still faces the same fundamental issue -- the arg
>>>> to the my_undef invocations (i.e. x) gets expanded first; thus
>>>> the %undef inside the macro sees esp+4 and esp+8 instead
>>>> of x, and fails. What you'd need is a means to prevent the ex-
>>>> pansion -- look for e.g. %# in 4.1.4 of the manual.txt which is
>>>> attached to SF #1842438; it implements exactly that -- I once
>>>> filed SF #829879 for this feature.
>>>>
>>>>
>>> Yeah, I know that it gets expanded. I'm just completely out of
>>> time to get closer look at. And perhaps Keith has some idea of
>>> fixing endless loop by other way. So I would better wait for
>>> his opinion.
>>>
>>> Thanks!
>>>
>>> -- Cyrill
>>>
>>>
>>
>> I'll take a look. -Keith
>>
>
> Your proposal seems fine, tests out fine as well. I can't vouch for any
> deep implications, but considering the run-away impact an interminable
> macro recursion may have, giving NASM a solid means to "recover" so the
> dev can address such an error is good enough for now.

Thanks for review Keith! I'll push the commit then.

>
> Anon is also correct in that we would need a special directive to
> instruct the delay of macro expansion, although I don't see this as
> critical or even high priority at the moment. The intermediate solution
> for this is, don't use indirection if it is not needed... an inline
> %undef should be sufficient.
>

ok

-- Cyrill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: preprocessor hang?

2009-11-20T21:52:23Z

Keith Kanios wrote:

> Cyrill Gorcunov wrote:
>
>> On Wed, Nov 18, 2009 at 12:48:46PM -0800, anonymous coward wrote:
>>
>>
>>>>> I suppose we may need Keith to take a look on. CC'ed.
>>>>>
>>>>>
>>>> Keith, it seems [...]
>>>>
>>>>
>>> Btw, after you manage to fix this recursion problem, the code
>>> in question still faces the same fundamental issue -- the arg
>>> to the my_undef invocations (i.e. x) gets expanded first; thus
>>> the %undef inside the macro sees esp+4 and esp+8 instead
>>> of x, and fails. What you'd need is a means to prevent the ex-
>>> pansion -- look for e.g. %# in 4.1.4 of the manual.txt which is
>>> attached to SF #1842438; it implements exactly that -- I once
>>> filed SF #829879 for this feature.
>>>
>>>
>>>
>> Yeah, I know that it gets expanded. I'm just completely out of
>> time to get closer look at. And perhaps Keith has some idea of
>> fixing endless loop by other way. So I would better wait for
>> his opinion.
>>
>> Thanks!
>>
>> -- Cyrill
>>
>>
>>
>
> I'll take a look. -Keith
>
>

Your proposal seems fine, tests out fine as well. I can't vouch for any
deep implications, but considering the run-away impact an interminable
macro recursion may have, giving NASM a solid means to "recover" so the
dev can address such an error is good enough for now.

Anon is also correct in that we would need a special directive to
instruct the delay of macro expansion, although I don't see this as
critical or even high priority at the moment. The intermediate solution
for this is, don't use indirection if it is not needed... an inline
%undef should be sufficient.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel

Re: preprocessor hang?

2009-11-20T20:54:01Z

Cyrill Gorcunov wrote:

> On Wed, Nov 18, 2009 at 12:48:46PM -0800, anonymous coward wrote:
>
>>>> I suppose we may need Keith to take a look on. CC'ed.
>>>>
>>> Keith, it seems [...]
>>>
>> Btw, after you manage to fix this recursion problem, the code
>> in question still faces the same fundamental issue -- the arg
>> to the my_undef invocations (i.e. x) gets expanded first; thus
>> the %undef inside the macro sees esp+4 and esp+8 instead
>> of x, and fails. What you'd need is a means to prevent the ex-
>> pansion -- look for e.g. %# in 4.1.4 of the manual.txt which is
>> attached to SF #1842438; it implements exactly that -- I once
>> filed SF #829879 for this feature.
>>
>>
>
> Yeah, I know that it gets expanded. I'm just completely out of
> time to get closer look at. And perhaps Keith has some idea of
> fixing endless loop by other way. So I would better wait for
> his opinion.
>
> Thanks!
>
> -- Cyrill
>
>

I'll take a look. -Keith

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nasm-devel mailing list
Nasm-devel@...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

From forum: nasm-devel