nasm-devel — NASM development work

Re: [Nasm-devel] NASM 2.11.09rc2

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

On Fri, Jan 15, 2016 at 11:10:53AM -0800, H. Peter Anvin wrote:
> I have pushed out an rc2 of NASM 2.11.09.  I think we should push out
> 2.11.09 soon.

One critical bug there -- ffmpeg building on mac platform. I still out
of time, but hopefully continue on the weekend. Sigh, I need at least
36 hours in the day :)

[Nasm-devel] NASM 2.11.09rc2

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

I have pushed out an rc2 of NASM 2.11.09.  I think we should push out
2.11.09 soon.

	-hpa

Re: [Nasm-devel] Fwd: Debugging programs made with nasm in gdb/ddd.

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

On Sun, Dec 27, 2015 at 08:45:25AM +0100, Guillermo Bernaldo de Quiros Maraver wrote:
> Hi, good morning,
> 
> I'm new in the mailing list, so, my name is Guillermo. I'm learning to
> write assembly code with several books such as Duntemann and Irvine books
> too so I'm sorry if I ask quite basic questions.
> 
> I've installed an OpenBSD Operating System in a INTEL I7 of 64bit and I'm
> trying to debug some applications made by myself with gdb or ddd and built
> with nasm (Version 2.11.08). (More information next).
> 
> My problem is when I launch gdb or ddd I can't debug the software. With DDD
> for example, I can't put breakpoints or I can't go step by step into the
> code and I don't know why. With GDB the problem is similar, in this case at
> least I can go step by step but I can't see the source code neither the
> instructions. Just I can see the addresses of the instructions and I don't
> know why  (Next you have the output of a session with GDB).
> 
> Of course, the program was built with debugging support. I tried dwarf and
> stabs but neither works to me.
> 
> Someone can help me? I need debug support because I'm learning to program
> software and if I don't have a debugger I won't learn anything but a lot of
> theory.

Hi Guillermo! A fear we've an incomplete support of
the debugging formats. Mind to ping guys on forum.nasm.us?
IIRC there were some worarounds but I'm not sure.

[Nasm-devel] Fwd: Debugging programs made with nasm in gdb/ddd.

[Guillermo B. de Q. M. <deb...@gm...>]

Hi, good morning,

I'm new in the mailing list, so, my name is Guillermo. I'm learning to
write assembly code with several books such as Duntemann and Irvine books
too so I'm sorry if I ask quite basic questions.

I've installed an OpenBSD Operating System in a INTEL I7 of 64bit and I'm
trying to debug some applications made by myself with gdb or ddd and built
with nasm (Version 2.11.08). (More information next).

My problem is when I launch gdb or ddd I can't debug the software. With DDD
for example, I can't put breakpoints or I can't go step by step into the
code and I don't know why. With GDB the problem is similar, in this case at
least I can go step by step but I can't see the source code neither the
instructions. Just I can see the addresses of the instructions and I don't
know why  (Next you have the output of a session with GDB).

Of course, the program was built with debugging support. I tried dwarf and
stabs but neither works to me.

Someone can help me? I need debug support because I'm learning to program
software and if I don't have a debugger I won't learn anything but a lot of
theory.

Here I put the contents of the Makefile:
all:
nasm -l main.lst -f elf64 -g -F stabs main.asm
gcc -gstabs -o main main.o

Here, the contents of the assembly program:
default rel

section .data

section .bss

section .text
global main

main:
  nop

    pop rax
    pop rbx
    pop rcx

  mov eax,1 ;
  mov edi,0 ;
    syscall

  nop


Next I put an example of my problem with gdb:

(gdb) start
Breakpoint 2 at 0x17c914700b10
Starting program:
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
Breakpoint 2 at 0x88508100b10
0x0000088508100b10 in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb) disassemble
Dump of assembler code for function main:
0x0000088508100b10 <main+0>: nop
0x0000088508100b11 <main+1>: pop    %rax
0x0000088508100b12 <main+2>: pop    %rbx
0x0000088508100b13 <main+3>: pop    %rcx
0x0000088508100b14 <main+4>: mov    $0x1,%eax
0x0000088508100b19 <main+9>: mov    $0x0,%edi
0x0000088508100b1e <main+14>: syscall
0x0000088508100b20 <main+16>: nop
0x0000088508100b21 <main+17>: nop
0x0000088508100b22 <main+18>: nop
0x0000088508100b23 <main+19>: nop
End of assembler dump.
(gdb) stepi
0x0000088508100b11 in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb)
0x0000088508100b12 in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb)
0x0000088508100b13 in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb)
0x0000088508100b14 in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb)
0x0000088508100b19 in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb)
0x0000088508100b1e in main () from
/home/debugbsd/Projects/Assembly_Language/GettingArguments/main
(gdb)

Program exited normally.
(gdb)

Thanks in advance,
Guille

Re: [Nasm-devel] nasm in 32/64kb

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

On 11/15/15 19:23, Daniel Roskams wrote:
> This might be the wrong place to ask. I'm not really sure, but if I am
> posting to the wrong place then please tell me.
> 
> I have been developing a real mode OS recently. I've gotten to the stage
> where I know the executable formats and memory layout, etc, so I first
> want to know if it is possible to fit a port of NASM into 32kb (half of
> a real mode segment). The other 32kb would be used for assembly code.
> 
> Preferably everything would be in a single segment, but I wouldn't mind
> if NASM had to fit into 64kb and then have another 64kb segment for data
> and stuff like that.
> 
> I don't need any of the following:
> * support for output format other than flat binary
> * preprocessor (no macros needed)
> * instructions above 80386
> 

We used to have a version which could run in DOS real mode using the
"huge" memory model.  What you are proposing is not realistic at all for
NASM.

	-hpa

Re: [Nasm-devel] nasm in 32/64kb

[Brian R. <bre...@mu...>]

> So, given that, should I try to port NASM or write my own assembler?

My gut instinct would be port something other than Nasm. You're
probably going to need to cut several corners and omit various
features in order to meet those kinds of memory constraints. Nasm has
support for multiple chip sets, multiple output file formats, multiple
optimization passes. I suspect if you look around some, you'll find a
more minimal assembler (with an appropriate license) that you can use
as a jumping-off point.

Alternately, start by writing your own assembler that has the absolute
minimum number of features that you need, and then build it up to make
it more usable until you hit your size limit.

b

[Nasm-devel] nasm in 32/64kb

[Daniel R. <roc...@ri...>]

This might be the wrong place to ask. I'm not really sure, but if I am
posting to the wrong place then please tell me.

I have been developing a real mode OS recently. I've gotten to the stage
where I know the executable formats and memory layout, etc, so I first
want to know if it is possible to fit a port of NASM into 32kb (half of
a real mode segment). The other 32kb would be used for assembly code.

Preferably everything would be in a single segment, but I wouldn't mind
if NASM had to fit into 64kb and then have another 64kb segment for data
and stuff like that.

I don't need any of the following:
* support for output format other than flat binary
* preprocessor (no macros needed)
* instructions above 80386

Memory map (basic):

segment    usage
----------------------------------------
0x0000     IVT, BDA, unused memory
0x1000     Stack segment
0x2000     Kernel (syscalls, runtime libs)
0x3000     Shell
0x4000     User's programs
(0x5000)   (nasm data)
0x7000     end of usable conventional memory

The executable format I chose is the COM file format (64kb max and ORG
0x100). There isn't a PSP.

So, given that, should I try to port NASM or write my own assembler?
Would it fit into the given size? Older versions of NASM for DOS were
almost 500 kb. It seems that from this, NASM will never fit into a
64kb segment. But removing the preprocessor and >386 instructions might
make it JUST small enough to fit... and I will be rewriting the whole
thing in assembler, and assembler is a lot smaller than C. So it might
fit in a segment if I could get the data in another segment.

--
Daniel

[Nasm-devel] [PATCH] Optionally allowing BITS 64 in OMF

[Knut S. O. <bir...@an...>]

Hi!

Using NASM to do some boot strapping code and ran into trouble when trying to emit a few 64-bit instructions in the OMF object file doing the mode switching.  While I can see how the "error: obj output format does not support 64-bit code" message can be a useful reality check for application programmers, it prevents low-level programmers from doing what they want.  It if was just a harmless warning, it wouldn't be so bad, but it turns BITS 64 into BITS 16. The main trick to mixing 64-bit code into OMF and other 32-bit output formats is to avoid 64-bit sized fixups, which normally isn't too hard.

My proposal is to add a switch to NASM to allow emitting 64-bit code in output formats that aren't 64-bit capable: 
	--allow-64bit-code-anywhere

Kind Regards,
 bird.

Signed-off-by: Knut St. Osmundsen <bir...@an...>
---
From 4f54c40fa3f23eaf85f3b4d672900690252cca70 Mon Sep 17 00:00:00 2001
From: "Knut St. Osmundsen" <bir...@an...>
Date: Tue, 10 Nov 2015 22:00:21 +0100
Subject: [PATCH] New option --allow-64bit-code-anywhere for allowing 64-bit
 code in output formats that aren't 64-bit capable, at the user's own risk.

From: bird <bi...@an...>

---
 doc/nasmdoc.src | 10 ++++++++++
 nasm.c          | 13 +++++++++++--
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/doc/nasmdoc.src b/doc/nasmdoc.src
index e468248..51c8c56 100644
--- a/doc/nasmdoc.src
+++ b/doc/nasmdoc.src
@@ -1010,6 +1010,16 @@ underscore to all global and external variables, as C sometimes
 (but not always) likes it.
 
 
+\S{opt-64bitcode} The \i\c{--allow-64bit-code-anywhere} Option.
+
+The \c{--allow-64bit-code-anywhere} option allows using 64-bit
+instructions in a 32-bit or 16-bit output format.  This is useful
+in a few situations, such as when writing code switching from
+32-bit to 64-bit mode and linking into a 32-bit module.  However,
+it is important to be aware of the restriction the output format
+poses on you in terms of relocations.  Use with caution!
+
+
 \S{nasmenv} The \i\c{NASMENV} \i{Environment} Variable
 
 If you define an environment variable called \c{NASMENV}, the program
diff --git a/nasm.c b/nasm.c
index 8557b4d..401eb78 100644
--- a/nasm.c
+++ b/nasm.c
@@ -88,6 +88,7 @@ static int using_debug_info, opt_verbose_info;
 bool tasm_compatible_mode = false;
 int pass0, passn;
 int maxbits = 0;
+static bool allow_64bit_code_anywhere = false;
 int globalrel = 0;
 int globalbnd = 0;
 
@@ -616,9 +617,11 @@ struct textargs {
 
 #define OPT_PREFIX 0
 #define OPT_POSTFIX 1
+#define OPT_64BIT_CODE_ANYWHERE 2
 struct textargs textopts[] = {
     {"prefix", OPT_PREFIX},
     {"postfix", OPT_POSTFIX},
+    {"allow-64bit-code-anywhere", OPT_64BIT_CODE_ANYWHERE},
     {NULL, 0}
 };
 
@@ -804,7 +807,10 @@ static bool process_arg(char *p, char *q)
                  "    -h          show invocation summary and exit\n\n"
                  "--prefix,--postfix\n"
                  "  this options prepend or append the given argument to all\n"
-                 "  extern and global variables\n\n"
+                 "  extern and global variables\n"
+                 "--allow-64bit-code-anywhere\n"
+                 "  do not restrict 64-bit code to 64-bit capable output\n"
+                 "  formats (use with care, no complaining)\n\n"
                  "Warnings:\n");
             for (i = 0; i <= ERR_WARN_MAX; i++)
                 printf("    %-23s %s (default %s)\n",
@@ -971,6 +977,9 @@ set_warning:
                         }
                         break;
                     }
+                case OPT_64BIT_CODE_ANYWHERE:
+                    allow_64bit_code_anywhere = true;
+                    break;
                 default:
                     {
                         nasm_error(ERR_NONFATAL | ERR_NOFILE | ERR_USAGE,
@@ -2088,7 +2097,7 @@ static int get_bits(char *value)
                          "cannot specify 64-bit segment on processor below an x86-64");
             i = 16;
         }
-        if (i != maxbits) {
+        if (i != maxbits && !allow_64bit_code_anywhere) {
             nasm_error(ERR_NONFATAL,
                          "%s output format does not support 64-bit code",
                          ofmt->shortname);
-- 
2.4.1

Re: [Nasm-devel] [nasm:master] disasm: Fix for disassembly of BOUND

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

On 11/05/15 12:51, Mark Scott wrote:
>>>
>>> So, I believe the logic should in fact be the exactly same logic that we
>>> have for VEX:
>>>
>>>            if (segsize == 64 || (data[1] & 0xc0) == 0xc0) {
>>
>> Ah, good point! Thanks for clarification, Peter! I'll fix
>>
> 
> Apologies for the mistake, and thanks for spotting!
> 

No worries, thank you for spotting the original problem!

	-hpa

Re: [Nasm-devel] [nasm:master] disasm: Fix for disassembly of BOUND

[Mark S. <na...@ms...>]

On 4 Nov 2015, at 19:30, Cyrill Gorcunov wrote:

> On Wed, Nov 04, 2015 at 10:51:36AM -0800, H. Peter Anvin wrote:
>>> 
>>> Signed-off-by: Mark Scott <na...@ms...>
>>> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
>>> 
>> 
>> This is wrong, though; EVEX is permitted in 32-bit mode just as VEX is.
>> 
>> The key thing is that bits [7:5] have to be 1 in 32-bit mode.  It is
>> unclear what happens if these bits are 110 as that depends on if it is
>> decoded using the modr/m decoder or not.  For VEX prefixes we accept
>> them as VEX in that case, which may not match the CPU.
>> 
>> The evex_p0 test seems to have been taken out of thin air; I don't think
>> that is a requirement for EVEX.
>> 
>> So, I believe the logic should in fact be the exactly same logic that we
>> have for VEX:
>> 
>>            if (segsize == 64 || (data[1] & 0xc0) == 0xc0) {
> 
> Ah, good point! Thanks for clarification, Peter! I'll fix
> 

Apologies for the mistake, and thanks for spotting!

Mark

Re: [Nasm-devel] [nasm:master] disasm: Fix for disassembly of BOUND

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

On Wed, Nov 04, 2015 at 10:51:36AM -0800, H. Peter Anvin wrote:
> > 
> > Signed-off-by: Mark Scott <na...@ms...>
> > Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> > 
> 
> This is wrong, though; EVEX is permitted in 32-bit mode just as VEX is.
> 
> The key thing is that bits [7:5] have to be 1 in 32-bit mode.  It is
> unclear what happens if these bits are 110 as that depends on if it is
> decoded using the modr/m decoder or not.  For VEX prefixes we accept
> them as VEX in that case, which may not match the CPU.
> 
> The evex_p0 test seems to have been taken out of thin air; I don't think
> that is a requirement for EVEX.
> 
> So, I believe the logic should in fact be the exactly same logic that we
> have for VEX:
> 
>             if (segsize == 64 || (data[1] & 0xc0) == 0xc0) {

Ah, good point! Thanks for clarification, Peter! I'll fix

Re: [Nasm-devel] [nasm:master] disasm: Fix for disassembly of BOUND

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

On 11/03/15 12:12, nasm-bot for Mark Scott wrote:
> Commit-ID:  db6ecf9b76a25c465887946fe70e74b3dcdce234
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=db6ecf9b76a25c465887946fe70e74b3dcdce234
> Author:     Mark Scott <na...@ms...>
> AuthorDate: Tue, 3 Nov 2015 23:09:05 +0300
> Committer:  Cyrill Gorcunov <gor...@gm...>
> CommitDate: Tue, 3 Nov 2015 23:09:05 +0300
> 
> disasm: Fix for disassembly of BOUND
> 
> The opcode for BOUND, 62h, has a different meaning in long mode - it is the
> prefix for EVEX instructions. ndisasm did not take this into account and always
> tried to disassemble 62h back to an EVEX instruction.
> 
> Attached patch only permits EVEX disassembly if bitness is 64.
> In 16/32 bit mode 62h will be not be a prefix and so disassemble
> to BOUND.
> 
> Signed-off-by: Mark Scott <na...@ms...>
> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> 

This is wrong, though; EVEX is permitted in 32-bit mode just as VEX is.

The key thing is that bits [7:5] have to be 1 in 32-bit mode.  It is
unclear what happens if these bits are 110 as that depends on if it is
decoded using the modr/m decoder or not.  For VEX prefixes we accept
them as VEX in that case, which may not match the CPU.

The evex_p0 test seems to have been taken out of thin air; I don't think
that is a requirement for EVEX.

So, I believe the logic should in fact be the exactly same logic that we
have for VEX:

            if (segsize == 64 || (data[1] & 0xc0) == 0xc0) {

	-hpa

Re: [Nasm-devel] Bug 3392287

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

On Tue, Nov 03, 2015 at 06:57:46PM +0000, Mark Scott wrote:
>    Hi,
>    I've attached a patch
>    to http://bugzilla.nasm.us/show_bug.cgi?id=3392287 to fix a bug in
>    disassembling of the BOUND instruction.
>    Intel reused the opcode for its EVEX instructions because BOUND's 0x62 is
>    only valid in 16/32 bit mode, so we need to take into account the current
>    bitness when determining whether 0x62 is a prefix or an instruction.

Hi Mark, I saw it, thanks! Hopefully will pick it up today.

[Nasm-devel] Bug 3392287

[Mark S. <na...@ms...>]

Hi,

I've attached a patch to http://bugzilla.nasm.us/show_bug.cgi?id=3392287 to fix a bug in disassembling of the BOUND instruction.

Intel reused the opcode for its EVEX instructions because BOUND's 0x62 is only valid in 16/32 bit mode, so we need to take into account the current bitness when determining whether 0x62 is a prefix or an instruction.

Regards,

Mark Scott

Re: [Nasm-devel] [nasm:master] insns.dat: Add SMSW for 64 bit mode

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

On Tue, Sep 15, 2015 at 12:36:33PM -0700, H. Peter Anvin wrote:
> > @@ -1286,6 +1286,7 @@ SMSW		mem				[m:	0f 01 /4]				286
> >  SMSW		mem16				[m:	0f 01 /4]				286
> >  SMSW		reg16				[m:	o16 0f 01 /4]				286
> >  SMSW		reg32				[m:	o32 0f 01 /4]				386
> > +SMSW		reg64				[m:	o64 0f 01 /4]				X64
> >  STC		void				[	f9]					8086
> >  STD		void				[	fd]					8086
> >  STI		void				[	fb]					8086
> > 
> 
> In optimizing mode (only!) we really should generate this without a REX
> prefix since it is equivalent, though.  There are some patterns like
> that already (look for the OPT flag.)

Managed to miss the mail :) Thank, will do!

Re: [Nasm-devel] [nasm:master] insns.dat: Add SMSW for 64 bit mode

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

On 09/13/2015 06:33 AM, nasm-bot for Cyrill Gorcunov wrote:
> Commit-ID:  8ab77b59e2ae0de9bf4fc4294a605547bbc7ef6d
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=8ab77b59e2ae0de9bf4fc4294a605547bbc7ef6d
> Author:     Cyrill Gorcunov <gor...@gm...>
> AuthorDate: Sun, 13 Sep 2015 16:30:21 +0300
> Committer:  Cyrill Gorcunov <gor...@gm...>
> CommitDate: Sun, 13 Sep 2015 16:30:21 +0300
> 
> insns.dat: Add SMSW for 64 bit mode
> 
> http://bugzilla.nasm.us/show_bug.cgi?id=3392323
> 
> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> 
> 
> ---
>  insns.dat | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/insns.dat b/insns.dat
> index f6c0f9f..c3bf293 100644
> --- a/insns.dat
> +++ b/insns.dat
> @@ -1286,6 +1286,7 @@ SMSW		mem				[m:	0f 01 /4]				286
>  SMSW		mem16				[m:	0f 01 /4]				286
>  SMSW		reg16				[m:	o16 0f 01 /4]				286
>  SMSW		reg32				[m:	o32 0f 01 /4]				386
> +SMSW		reg64				[m:	o64 0f 01 /4]				X64
>  STC		void				[	f9]					8086
>  STD		void				[	fd]					8086
>  STI		void				[	fb]					8086
> 

In optimizing mode (only!) we really should generate this without a REX
prefix since it is equivalent, though.  There are some patterns like
that already (look for the OPT flag.)

	-hpa

[Nasm-devel] oh yeah

[ty n. <aa...@ci...>]

 if you do build your own cpu gpu audio cards etcetera make them
programmable integrated circuits and post tutorials on all aspects of how
to build develop and debug the little chips that you make.

make them by hand and slowly, and wire them transistor by transistor
and of course program them in assembly



you can do it
itll be fun

thanks

[Nasm-devel] just a quest for tutorials

[ty n. <aa...@ci...>]

for tutorials on writing Operating systems in assembly
As well as writing Digital signal processing software in assembly
like guitarix and rakarrack in assembly

As well as writing things like blender in assembly.
and for writing macintosh device drivers in assembly
especially for thinks like discreet video cards


Also, if you guys know how to build processors of your own, you should
totally build processors and audio and video cards and post tutorials on
them.

I have an architecture in mind, I think it is called multi-cored processors
for audio, where you can have multiple signals in going to different cores
but all of them are on the same audio card so it can be used with jackd.

that way I can have a mixer with USB inputs and USB output and have ability
to access all the different signals on that card. It will be fun

Thanks for the time and stuff

Re: [Nasm-devel] [nasm:master] output: outmac64 -- Fix the case when first hit matches the symbol

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

On 06/03/2015 12:29 AM, Cyrill Gorcunov wrote:
> On Tue, Jun 02, 2015 at 02:49:20PM -0700, H. Peter Anvin wrote:
>>>
>>> diff --git a/output/outmac64.c b/output/outmac64.c
>>> index c07dcbc..1d30e64 100644
>>> --- a/output/outmac64.c
>>> +++ b/output/outmac64.c
>>> @@ -304,7 +304,7 @@ static struct symbol *get_closest_section_symbol_by_offset(uint8_t fileindex, in
>>>  
>>>      for (sym = syms; sym; sym = sym->next) {
>>>          if ((sym->sect != NO_SECT) && (sym->sect == fileindex)) {
>>> -            if ((int64_t)sym->value >= offset)
>>> +            if ((int64_t)sym->value > offset)
>>>                  break;
>>>              nearest = sym;
>>>          }
>>>
>>
>> For performance scaling reasons it would be good if we could use a LLRB
>> tree for this, like we do in ELF.
> 
> Sounds good, will do (in next release then).
> 

Yes, not a point release kind of thing.

	-hpa

Re: [Nasm-devel] [nasm:master] output: outmac64 -- Fix the case when first hit matches the symbol

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

On Tue, Jun 02, 2015 at 02:49:20PM -0700, H. Peter Anvin wrote:
> > 
> > diff --git a/output/outmac64.c b/output/outmac64.c
> > index c07dcbc..1d30e64 100644
> > --- a/output/outmac64.c
> > +++ b/output/outmac64.c
> > @@ -304,7 +304,7 @@ static struct symbol *get_closest_section_symbol_by_offset(uint8_t fileindex, in
> >  
> >      for (sym = syms; sym; sym = sym->next) {
> >          if ((sym->sect != NO_SECT) && (sym->sect == fileindex)) {
> > -            if ((int64_t)sym->value >= offset)
> > +            if ((int64_t)sym->value > offset)
> >                  break;
> >              nearest = sym;
> >          }
> > 
> 
> For performance scaling reasons it would be good if we could use a LLRB
> tree for this, like we do in ELF.

Sounds good, will do (in next release then).

Re: [Nasm-devel] [nasm:master] out: maco64 -- Fix erroneously small write for OUT_REL4ADR

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

On Tue, Jun 02, 2015 at 02:49:42PM -0700, H. Peter Anvin wrote:
> 
> If this solves the problems with MachO, we should make a point release.

Will do on the week (need some time to review again the rest of the rel4
code for other archs).

Re: [Nasm-devel] [nasm:master] out: maco64 -- Fix erroneously small write for OUT_REL4ADR

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

On 06/02/2015 03:30 AM, nasm-bot for Delan Azabani wrote:
> Commit-ID:  5b730a197ad343d1e3836feb49888701b9221ade
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=5b730a197ad343d1e3836feb49888701b9221ade
> Author:     Delan Azabani <de...@az...>
> AuthorDate: Mon, 1 Jun 2015 05:56:11 +0800
> Committer:  Cyrill Gorcunov <gor...@gm...>
> CommitDate: Tue, 2 Jun 2015 13:22:32 +0300
> 
> out: maco64 -- Fix erroneously small write for OUT_REL4ADR
> 
> Ensure that the int64_t offset value, which ultimately comes from an
> int64_t value in gencode() (assemble.c:1906), is completely written to
> the temporary buffer, instead of merely its least significant 32 bits.
> 
> Prior to this change, WRITELONG was used instead of WRITEDLONG, which
> resulted in add_reloc being passed an int64_t "reloff" whose least
> significant 32 bits were those from the aforementioned offset value,
> and whose most significant 32 bits were stack garbage from "mydata".
> 
> This led to get_closest_section_symbol_by_offset() attempting to search
> for extremely large values of "offset" among the symbols in "syms",
> which meant that the last symbol with a matching section number would
> always win the symbol search.
> 
> In effect, this clobbered the resultant relocation information, such
> that all entries would be resolved with the same symbol.
> 
> Test output can be found here
> 
> https://www.azabani.com/patch/2/output.txt
> 
> This patch fixes
> 
> http://bugzilla.nasm.us/show_bug.cgi?id=3392306
> 
> Signed-off-by: Delan Azabani <de...@az...>
> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> 

If this solves the problems with MachO, we should make a point release.

	-hpa

Re: [Nasm-devel] [nasm:master] output: outmac64 -- Fix the case when first hit matches the symbol

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

On 05/09/2015 08:09 AM, nasm-bot for Cyrill Gorcunov wrote:
> Commit-ID:  4920a0324348716d6ab5106e65508496241dc7a2
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=4920a0324348716d6ab5106e65508496241dc7a2
> Author:     Cyrill Gorcunov <gor...@gm...>
> AuthorDate: Sat, 9 May 2015 18:07:47 +0300
> Committer:  Cyrill Gorcunov <gor...@gm...>
> CommitDate: Sat, 9 May 2015 18:07:47 +0300
> 
> output: outmac64 -- Fix the case when first hit matches the symbol
> 
> In case if we're looking up for a symbol and it's first
> one in symbol table we might endup with error because of
> using GE here (78f477b35f) ending cycle with @nearest = NULL.
> 
> http://bugzilla.nasm.us/show_bug.cgi?id=3392306
> 
> Reprted-by: Benjamin Randazzo <ben...@li...>
> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> 
> 
> ---
>  output/outmac64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/output/outmac64.c b/output/outmac64.c
> index c07dcbc..1d30e64 100644
> --- a/output/outmac64.c
> +++ b/output/outmac64.c
> @@ -304,7 +304,7 @@ static struct symbol *get_closest_section_symbol_by_offset(uint8_t fileindex, in
>  
>      for (sym = syms; sym; sym = sym->next) {
>          if ((sym->sect != NO_SECT) && (sym->sect == fileindex)) {
> -            if ((int64_t)sym->value >= offset)
> +            if ((int64_t)sym->value > offset)
>                  break;
>              nearest = sym;
>          }
> 

For performance scaling reasons it would be good if we could use a LLRB
tree for this, like we do in ELF.

	-hpa

Re: [Nasm-devel] [PATCH] Fix erroneously small write for OUT_REL4ADR

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

On Mon, Jun 01, 2015 at 05:56:11AM +0800, Delan Azabani wrote:
> Ensure that the int64_t offset value, which ultimately comes from an
> int64_t value in gencode() (assemble.c:1906), is completely written to
> the temporary buffer, instead of merely its least significant 32 bits.

Thank you! I didn't look into the details yet, hopefully on the week.

[Nasm-devel] [PATCH] Fix erroneously small write for OUT_REL4ADR

[Delan A. <de...@az...>]

Ensure that the int64_t offset value, which ultimately comes from an
int64_t value in gencode() (assemble.c:1906), is completely written to
the temporary buffer, instead of merely its least significant 32 bits.

Prior to this change, WRITELONG was used instead of WRITEDLONG, which
resulted in add_reloc being passed an int64_t "reloff" whose least
significant 32 bits were those from the aforementioned offset value,
and whose most significant 32 bits were stack garbage from "mydata".

This led to get_closest_section_symbol_by_offset() attempting to search
for extremely large values of "offset" among the symbols in "syms",
which meant that the last symbol with a matching section number would
always win the symbol search.

In effect, this clobbered the resultant relocation information, such
that all entries would be resolved with the same symbol.

Test output can be found here

https://www.azabani.com/patch/2/output.txt

This patch fixes

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

Signed-off-by: Delan Azabani <de...@az...>
---
 output/outmac64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/output/outmac64.c b/output/outmac64.c
index 1d30e64..461fa32 100644
--- a/output/outmac64.c
+++ b/output/outmac64.c
@@ -588,7 +588,7 @@ static void macho_output(int32_t secto, const void *data,
 
     case OUT_REL4ADR:
         p = mydata;
-        WRITELONG(p, *(int64_t *)data + 4 - size);
+        WRITEDLONG(p, *(int64_t *)data + 4 - size);
 
         if (section == secto)
             nasm_error(ERR_PANIC, "intra-section OUT_REL4ADR");
-- 
2.3.2 (Apple Git-55)