nasm-devel — NASM development work

Re: [Nasm-devel] Syslinux 6.03 build is broken by nasm upgrade 2.11.05 to 2.11.06

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

On Mon, Nov 24, 2014 at 11:06:54AM +0000, Andrew Walrond wrote:
> Don't know if this is syslinux or nasm problem, but since HPA seems 
> active in both, I thought I'd post it here. Build fails like this:
> 
> nasm -f elf -Ox  -g -F dwarf -DDATE_STR="'6.03'" \
>          -DHEXDATE="0x54730e41" \
>          -Di386 \
>          -I/source/sys/syslinux/core/ \
>          -l ldlinux.lsr -o ldlinux.o -MP -MD ./.ldlinux.o.d 
> /source/sys/syslinux/core/ldlinux.asm
> diskstart.inc:438: error: symbol references not supported in 
> preprocess-only mode
> diskstart.inc:438: error: non-constant value given to `%if'
> diskstart.inc:439: error: symbol references not supported in 
> preprocess-only mode
> diskstart.inc:439: error: non-constant value given to `%assign'
> /source/sys/syslinux/core/ldlinux.asm:26: fatal: unable to open include 
> file `head.inc'
> /source/sys/syslinux/core/Makefile:156: recipe for target 'ldlinux.o' failed
> 
> Hope that's useful.

Looks like -M option get screwed. Thanks for report I will try to
take a look in a couple of days.

[Nasm-devel] Syslinux 6.03 build is broken by nasm upgrade 2.11.05 to 2.11.06

[Andrew W. <an...@wa...>]

Don't know if this is syslinux or nasm problem, but since HPA seems 
active in both, I thought I'd post it here. Build fails like this:

nasm -f elf -Ox  -g -F dwarf -DDATE_STR="'6.03'" \
         -DHEXDATE="0x54730e41" \
         -Di386 \
         -I/source/sys/syslinux/core/ \
         -l ldlinux.lsr -o ldlinux.o -MP -MD ./.ldlinux.o.d 
/source/sys/syslinux/core/ldlinux.asm
diskstart.inc:438: error: symbol references not supported in 
preprocess-only mode
diskstart.inc:438: error: non-constant value given to `%if'
diskstart.inc:439: error: symbol references not supported in 
preprocess-only mode
diskstart.inc:439: error: non-constant value given to `%assign'
/source/sys/syslinux/core/ldlinux.asm:26: fatal: unable to open include 
file `head.inc'
/source/sys/syslinux/core/Makefile:156: recipe for target 'ldlinux.o' failed

Hope that's useful.

-- 
Andrew Walrond

[Nasm-devel] [PATCH] Fix 256-bit vmovntps

[Henrik G. <he...@gr...>]

Signed-off-by: Henrik Gramner <he...@gr...>
---
 insns.dat | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/insns.dat b/insns.dat
index 4191075..baa7b9d 100644
--- a/insns.dat
+++ b/insns.dat
@@ -2490,7 +2490,7 @@ VMOVNTDQA	xmmreg,mem128			[rm:	vex.128.66.0f38 2a /r]			AVX,SANDYBRIDGE
 VMOVNTPD	mem128,xmmreg			[mr:	vex.128.66.0f 2b /r]			AVX,SANDYBRIDGE
 VMOVNTPD	mem256,ymmreg			[mr:	vex.256.66.0f 2b /r]			AVX,SANDYBRIDGE
 VMOVNTPS	mem128,xmmreg			[mr:	vex.128.0f 2b /r]			AVX,SANDYBRIDGE
-VMOVNTPS	mem128,ymmreg			[mr:	vex.256.0f 2b /r]			AVX,SANDYBRIDGE
+VMOVNTPS	mem256,ymmreg			[mr:	vex.256.0f 2b /r]			AVX,SANDYBRIDGE
 VMOVSD		xmmreg,xmmreg*,xmmreg		[rvm:	vex.nds.lig.f2.0f 10 /r]		AVX,SANDYBRIDGE
 VMOVSD		xmmreg,mem64			[rm:	vex.lig.f2.0f 10 /r]			AVX,SANDYBRIDGE
 VMOVSD		xmmreg,xmmreg*,xmmreg		[mvr:	vex.nds.lig.f2.0f 11 /r]		AVX,SANDYBRIDGE
-- 
1.8.3.2

Re: [Nasm-devel] Override extern with global for header files

[Lars M. <lar...@te...>]

-------- Weitergeleitete Nachricht --------
Betreff: 	Re: [Nasm-devel] Override extern with global for header files
Datum: 	Sat, 18 Oct 2014 17:17:12 +0200
Von: 	Lars Maier <lar...@te...>
An: 	suresh babu <k_s...@ya...>



Look at this:
http://repo.or.cz/w/nasm/externdefs.git

for me and my projects it works very well. Maybe there are some
situations that will break the patch.
In addition to that there is the a message, that declaring local labels
is experimental.
Works with omf output format and elf.

The externdefs work like this: At the second pass, passn == 2, the
externdef directive checks if the label is locally defined,
if so, then it does the same as the global directive would do, if not,
then its handled as extern.

Re: [Nasm-devel] Override extern with global for header files

[suresh b. <k_s...@ya...>]

Hi Lars,

We can do it.  externdef as  a user-level directive for the extern primitive directive.

regards,
sureshbk.



On Saturday, October 18, 2014 4:46 PM, Lars Maier <lar...@te...> wrote:
 


Okay. So why we don't just introduce externdef as keyword?

This would be less work, than caching the extern definitions and
      wait for their redefinition.


Am 13.10.2014 um 02:03 schrieb suresh babu:

Yes right exactly and thanks for more clear clarification.
>
>
>
>
>On Sunday, October 12, 2014 8:17 AM, anonymous coward <nas...@us...> wrote:
> 
>
>
>>> You mean like MASM's EXTERNDEF?
>>>
>>> http://msdn.microsoft.com/en-us/library/91sxd44w.aspx
>>
>> To make it clear, here is an example:
>>
>> myfunc.inc:
>>
>> %define MY_FUNC_FLAG_A    0x0001
>> %define MY_FUNC_FLAG_B    0x0002
>> [...]
>>
>> ; myfunc(param1, param2) : result
>> ; this function does something and returns a value
                of it
>> [extern myfunc]
>>
>>
>> myfunc.asm:
>> %include 'include/myfunc.inc'
>> [global myfunc]
>>
>> section .code
>>
>> myfunc:
>>      push ebp
>>      mov ebp, esp
>>      mov eax, [ebp+0x08]
>>      test eax, MY_FUNC_FLAG_A
>>      jnz .flagA
>> [...]
>>
>>
>> otherfile.asm
>> %include 'include/myfunc.inc'
>>
>> section .code
>>
>>    push 0
>>    push MY_FUNC_FLAG_A
>>    call myfunc
>
>Yup, that's the EXTERNDEF behavior.
>
>You should called it that.
>
>------------------------------------------------------------------------------
>Meet PCI DSS 3.0 Compliance Requirements with EventLog
                Analyzer
>Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box
                PCI DSS Reports
>Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
                White paper
>Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
                EventLog Analyzer
>http://p.sf.net/sfu/Zoho
>_______________________________________________
>Nasm-devel mailing list
>Nas...@li...
>https://lists.sourceforge.net/lists/listinfo/nasm-devel
>
>
>
>
>
>------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho
>
>
>_______________________________________________
Nasm-devel mailing list Nas...@li... https://lists.sourceforge.net/lists/listinfo/nasm-devel 

Re: [Nasm-devel] Override extern with global for header files

[Lars M. <lar...@te...>]

Okay. So why we don't just introduce externdef as keyword?

This would be less work, than caching the extern definitions and wait 
for their redefinition.


Am 13.10.2014 um 02:03 schrieb suresh babu:
> Yes right exactly and thanks for more clear clarification.
>
>
> On Sunday, October 12, 2014 8:17 AM, anonymous coward 
> <nas...@us...> wrote:
>
>
> >> You mean like MASM's EXTERNDEF?
> >>
> >> http://msdn.microsoft.com/en-us/library/91sxd44w.aspx
> >
> > To make it clear, here is an example:
> >
> > myfunc.inc:
> >
> > %define MY_FUNC_FLAG_A    0x0001
> > %define MY_FUNC_FLAG_B    0x0002
> > [...]
> >
> > ; myfunc(param1, param2) : result
> > ; this function does something and returns a value of it
> > [extern myfunc]
> >
> >
> > myfunc.asm:
> > %include 'include/myfunc.inc'
> > [global myfunc]
> >
> > section .code
> >
> > myfunc:
> >      push ebp
> >      mov ebp, esp
> >      mov eax, [ebp+0x08]
> >      test eax, MY_FUNC_FLAG_A
> >      jnz .flagA
> > [...]
> >
> >
> > otherfile.asm
> > %include 'include/myfunc.inc'
> >
> > section .code
> >
> >    push 0
> >    push MY_FUNC_FLAG_A
> >    call myfunc
>
> Yup, that's the EXTERNDEF behavior.
>
> You should called it that.
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Nasm-devel mailing list
> Nas...@li... <mailto:Nas...@li...>
> https://lists.sourceforge.net/lists/listinfo/nasm-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
>
>
> _______________________________________________
> Nasm-devel mailing list
> Nas...@li...
> https://lists.sourceforge.net/lists/listinfo/nasm-devel

Re: [Nasm-devel] Override extern with global for header files

[suresh b. <k_s...@ya...>]

Yes right exactly and thanks for more clear clarification.



On Sunday, October 12, 2014 8:17 AM, anonymous coward <nas...@us...> wrote:
 


>> You mean like MASM's EXTERNDEF?
>>
>> http://msdn.microsoft.com/en-us/library/91sxd44w.aspx
>
> To make it clear, here is an example:
>
> myfunc.inc:
>
> %define MY_FUNC_FLAG_A     0x0001
> %define MY_FUNC_FLAG_B     0x0002
> [...]
>
> ; myfunc(param1, param2) : result
> ; this function does something and returns a value of it
> [extern myfunc]
>
>
> myfunc.asm:
> %include 'include/myfunc.inc'
> [global myfunc]
>
> section .code
>
> myfunc:
>      push ebp
>      mov ebp, esp
>      mov eax, [ebp+0x08]
>      test eax, MY_FUNC_FLAG_A
>      jnz .flagA
> [...]
>
>
> otherfile.asm
> %include 'include/myfunc.inc'
>
> section .code
>
>    push 0
>    push MY_FUNC_FLAG_A
>    call myfunc

Yup, that's the EXTERNDEF behavior.

You should called it that.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Nasm-devel mailing list
Nas...@li...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Re: [Nasm-devel] Override extern with global for header files

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

>> You mean like MASM's EXTERNDEF?
>>
>> http://msdn.microsoft.com/en-us/library/91sxd44w.aspx
>
> To make it clear, here is an example:
>
> myfunc.inc:
>
> %define MY_FUNC_FLAG_A     0x0001
> %define MY_FUNC_FLAG_B     0x0002
> [...]
>
> ; myfunc(param1, param2) : result
> ; this function does something and returns a value of it
> [extern myfunc]
>
>
> myfunc.asm:
> %include 'include/myfunc.inc'
> [global myfunc]
>
> section .code
>
> myfunc:
>      push ebp
>      mov ebp, esp
>      mov eax, [ebp+0x08]
>      test eax, MY_FUNC_FLAG_A
>      jnz .flagA
> [...]
>
>
> otherfile.asm
> %include 'include/myfunc.inc'
>
> section .code
>
>    push 0
>    push MY_FUNC_FLAG_A
>    call myfunc

Yup, that's the EXTERNDEF behavior.

You should called it that.

Re: [Nasm-devel] Override extern with global for header files

[Lars M. <lar...@te...>]

Hi,
today and yesterday I worked a bit at the feature we previously talked 
about.
This is not as easy as it might seems to be.

It took very long for me to understand the programm mechanics. Now I'm 
at the following point:
I can record extern definitions and prevent nasm from passing them to 
the ofmt. Although a redefinition as global is possible and they were 
treated as "unseen" labels. So the old function of a global label still 
works. There is just one problem: when passing the recorded extern 
labels, exept those wich are globals now, after the assembling is done, 
then the reloc adresses are broken in the output file. I guess this is 
because while assembling nasm is unable to resolve the label references. 
I would fix this, but I have no idea where and when this resolving takes 
places?


Just to make the problem clearer:

nasm -f elf test\externdef.asm

[extern externFunc]
[extern externFunc2]
[extern myFunc]

[global myFunc]

[section .text use32 class=code]

   ; just some senseless code to create references and relocs
   myFunc:
     push ebp
     mov ebp, esp
   .local:
     mov eax, 0x01
     jmp .local
     leave
     ret 4
   abc:
     call [externFunc]
     call [externFunc2]
     call [myFunc]
     ret 4




objdump -x test\externdef.o
nasm-2.11.05\test\externdef.o:     file format elf32-i386
nasm-2.11.05\test\externdef.o
architecture: i386, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000023  00000000  00000000  00000130  2**4
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
SYMBOL TABLE:
00000000 l    df *ABS*  00000000 test\externdef.asm
00000000 l    d  .text  00000000 .text
00000003 l       .text  00000000 myFunc.local
0000000e l       .text  00000000 abc
00000000         *UND*  00000000 externFunc
00000000         *UND*  00000000 externFunc2
00000000 g       .text  00000000 myFunc


RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000010 R_386_32          myFunc
00000016 R_386_32          myFunc
0000001c R_386_32          myFunc

Re: [Nasm-devel] Override extern with global for header files

[Lars M. <lar...@te...>]

Hi,

Am 02.10.2014 um 22:02 schrieb Cyrill Gorcunov:
> Hi Lars, sorry for delays! I'll reply hopefully on weekend once
> I get more free time. That said the email is seen and not lost.
I didn't expect any answer since I saw the date of the last activity. :D

Am 02.10.2014 um 06:54 schrieb suresh babu:
> If an extern is used in any program, it mean that the defined variable 
> / label / name is globally defined. Then why again making it a gloabl?

> You mean like MASM's EXTERNDEF?
>
> http://msdn.microsoft.com/en-us/library/91sxd44w.aspx

To make it clear, here is an example:

myfunc.inc:

%define MY_FUNC_FLAG_A     0x0001
%define MY_FUNC_FLAG_B     0x0002
[...]

; myfunc(param1, param2) : result
; this function does something and returns a value of it
[extern myfunc]


myfunc.asm:
%include 'include/myfunc.inc'
[global myfunc]

section .code

myfunc:
     push ebp
     mov ebp, esp
     mov eax, [ebp+0x08]
     test eax, MY_FUNC_FLAG_A
     jnz .flagA
[...]


otherfile.asm
%include 'include/myfunc.inc'

section .code

   push 0
   push MY_FUNC_FLAG_A
   call myfunc



Am 02.10.2014 um 17:31 schrieb H. Peter Anvin:
> Would you be willing to
> write up a patch?
I dont have much time in the next few weeks because university starts 
again,
but I'll do my best to find time and implement this feature, if wanted.
It would be great if you could support me if there are any questions.

Re: [Nasm-devel] Override extern with global for header files

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

> What if a defined extern could be redefined as global.

You mean like MASM's EXTERNDEF?

http://msdn.microsoft.com/en-us/library/91sxd44w.aspx

Re: [Nasm-devel] Override extern with global for header files

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

On Mon, Sep 29, 2014 at 01:39:51AM +0200, Lars Maier wrote:
...
> 
> I would love to from you!

Hi Lars, sorry for delays! I'll reply hopefully on weekend once
I get more free time. That said the email is seen and not lost.

Re: [Nasm-devel] Override extern with global for header files

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

On 09/28/2014 04:39 PM, Lars Maier wrote:
> Hello at all,
> I'm working a lot with nasm and after a while I created a little library
> I use in all nasm-Projects. Therefor some header files are very useful
> (e.g. defining constants and externs).
> I don't want to mess around with some macros for simple imports. I
> thought of a c-prototype-like symbol definition for externs. What if a
> defined extern could be redefined as global.
> 
> I had a look at the source code and found two possible solutions:
> 
> 1.) see http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l278
> one could allow in line 294, that externs could be redefined as global.
> By a quick look, I think, that this wouldn't be a problem for the
> labelmanager. find_lable simply returns the label and define_lable would
> refill it with the global singal data. The bigger problem is the ofmt,
> because the ofmt->symdef is explicitly called _once_ for each symbol.
> Looking at, for example, the objobj.c you can see, that symbols are
> stored in linked lists and there is no check for double names or
> something like that. -> Bad solution (update all objformats, looping
> through list for each symbol)
> 
> 2.) if somehow possible, and symbols do not need to passed to the ofmt
> directly after they were found (somehow context dependend), then you
> could buffer the extern symbols until the whole analysis is ready. every
> extern symbol that was not replaced by a global would then be passed the
> the ofmt. exclude extern symbols at
> http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l327 and introduce a
> new function, that loops through all symbols and passes the missing
> externs to the ofmt. call the function in the main function at the right
> place (maybe here: http://repo.or.cz/w/nasm.git/blob/HEAD:/nasm.c#l466).
> 
> I would love to from you!
> Lars
> 

It would seem like a reasonable thing to do, and is obviously use in C
to good effect.  I agree that option 2 would by far be preferable, and
it looks like you have thought of this a lot.  Would you be willing to
write up a patch?

	-hpa

Re: [Nasm-devel] Override extern with global for header files

[suresh b. <k_s...@ya...>]

Hi Lars,

If an extern is used in any program, it mean that the defined variable / label / name is globally defined.  Then why again making it a gloabl?

You said in your old mails that you are making a single library for all exe formats.  Can you give your objective of modifying the nasm and its purpose before we understand the code you are referring here.

DEVELOPING AN OPTIONs WINDOW FOR NASM
=======================================


I am interested to develop a simple window with options set through a menu to run nasm.  In the command line we give options but instead we can give them through a menu and save the options file similar to a project file in build systems.

Looking for suggestions and comments for my initiative.



regards,
sureshbk.



On Monday, September 29, 2014 5:25 AM, Lars Maier <lar...@te...> wrote:
 


Hello at all,
I'm working a lot with nasm and after a while I created a little library
I use in all nasm-Projects. Therefor some header files are very useful
(e.g. defining constants and externs).
I don't want to mess around with some macros for simple imports. I
thought of a c-prototype-like symbol definition for externs. What if a
defined extern could be redefined as global.

I had a look at the source code and found two possible solutions:

1.) see http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l278
one could allow in line 294, that externs could be redefined as global.
By a quick look, I think, that this wouldn't be a problem for the
labelmanager. find_lable simply returns the label and define_lable would
refill it with the global singal data. The bigger problem is the ofmt,
because the ofmt->symdef is explicitly called _once_ for each symbol.
Looking at, for example, the objobj.c you can see, that symbols are
stored in linked lists and there is no check for double names or
something like that. -> Bad solution (update all objformats, looping
through list for each symbol)

2.) if somehow possible, and symbols do not need to passed to the ofmt
directly after they were found (somehow context dependend), then you
could buffer the extern symbols until the whole analysis is ready. every
extern symbol that was not replaced by a global would then be passed the
the ofmt. exclude extern symbols at
http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l327 and introduce a
new function, that loops through all symbols and passes the missing
externs to the ofmt. call the function in the main function at the right
place (maybe here: http://repo.or.cz/w/nasm.git/blob/HEAD:/nasm.c#l466).

I would love to from you!
Lars




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Nasm-devel mailing list
Nas...@li...
https://lists.sourceforge.net/lists/listinfo/nasm-devel

[Nasm-devel] Override extern with global for header files

[Lars M. <lar...@te...>]

Hello at all,
I'm working a lot with nasm and after a while I created a little library
I use in all nasm-Projects. Therefor some header files are very useful
(e.g. defining constants and externs).
I don't want to mess around with some macros for simple imports. I
thought of a c-prototype-like symbol definition for externs. What if a
defined extern could be redefined as global.

I had a look at the source code and found two possible solutions:

1.) see http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l278
one could allow in line 294, that externs could be redefined as global.
By a quick look, I think, that this wouldn't be a problem for the
labelmanager. find_lable simply returns the label and define_lable would
refill it with the global singal data. The bigger problem is the ofmt,
because the ofmt->symdef is explicitly called _once_ for each symbol.
Looking at, for example, the objobj.c you can see, that symbols are
stored in linked lists and there is no check for double names or
something like that. -> Bad solution (update all objformats, looping
through list for each symbol)

2.) if somehow possible, and symbols do not need to passed to the ofmt
directly after they were found (somehow context dependend), then you
could buffer the extern symbols until the whole analysis is ready. every
extern symbol that was not replaced by a global would then be passed the
the ofmt. exclude extern symbols at
http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l327 and introduce a
new function, that loops through all symbols and passes the missing
externs to the ofmt. call the function in the main function at the right
place (maybe here: http://repo.or.cz/w/nasm.git/blob/HEAD:/nasm.c#l466).

I would love to from you!
Lars

Re: [Nasm-devel] [PATCH 0/2] Elf: Start code unification

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

On Wed, Sep 24, 2014 at 11:28:11AM -0700, H. Peter Anvin wrote:
> On 09/21/2014 02:09 AM, Cyrill Gorcunov wrote:
> > We've a number of files which almost copy/pasted for Elf32/32x/64
> > output formats, so when time permits I'm working on this code unification.
> > The final idea is to have a single Elf engine.
> > 
> > While been able to build nasm with gcc I would like to hear your
> > opinion on idea and if possible try to build nasm with patch applied
> > on other platforms.
> 
> Looks good to me.

OK, I'll merge it then. Actually I wanted to proceed in small steps but
not sure yet how to do that, thinking...

Re: [Nasm-devel] [PATCH 0/2] Elf: Start code unification

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

On 09/21/2014 02:09 AM, Cyrill Gorcunov wrote:
> We've a number of files which almost copy/pasted for Elf32/32x/64
> output formats, so when time permits I'm working on this code unification.
> The final idea is to have a single Elf engine.
> 
> While been able to build nasm with gcc I would like to hear your
> opinion on idea and if possible try to build nasm with patch applied
> on other platforms.

Looks good to me.

	-hpa

[Nasm-devel] [PATCH 2/2] output: elf -- Use common elf_ structures

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

Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---
 output/outelf32.c  | 86 +++++++++++++++------------------------------------
 output/outelf64.c  | 90 ++++++++++++++++--------------------------------------
 output/outelfx32.c | 89 ++++++++++++++++-------------------------------------
 3 files changed, 77 insertions(+), 188 deletions(-)

diff --git a/output/outelf32.c b/output/outelf32.c
index 462e5bc..af0547a 100644
--- a/output/outelf32.c
+++ b/output/outelf32.c
@@ -61,44 +61,8 @@
 
 #ifdef OF_ELF32
 
-/*
- * Relocation types.
- */
-struct Reloc {
-    struct Reloc *next;
-    int32_t address;            /* relative to _start_ of section */
-    int32_t symbol;             /*  symbol index */
-    int type;                   /* type of relocation */
-};
-
-struct Symbol {
-    struct rbtree symv;         /* symbol value and symbol rbtree */
-    int32_t strpos;             /* string table position of name */
-    int32_t section;            /* section ID of the symbol */
-    int type;                   /* symbol type */
-    int other;                  /* symbol visibility */
-    int32_t size;               /* size of symbol */
-    int32_t globnum;            /* symbol table offset if global */
-    struct Symbol *nextfwd;     /* list of unresolved-size symbols */
-    char *name;                 /* used temporarily if in above list */
-};
-
-struct Section {
-    struct SAA *data;
-    uint32_t len, size, nrelocs;
-    int32_t index;
-    int type;                   /* SHT_PROGBITS or SHT_NOBITS */
-    uint32_t align;             /* alignment: power of two */
-    uint32_t flags;             /* section flags */
-    char *name;
-    struct SAA *rel;
-    int32_t rellen;
-    struct Reloc *head, **tail;
-    struct rbtree *gsyms;       /* global symbols in section */
-};
-
 #define SECT_DELTA 32
-static struct Section **sects;
+static struct elf_section **sects;
 static int nsects, sectlen;
 
 #define SHSTR_DELTA 256
@@ -115,7 +79,7 @@ static struct RAA *bsym;
 static struct SAA *strs;
 static uint32_t strslen;
 
-static struct Symbol *fwds;
+static struct elf_symbol *fwds;
 
 static char elf_module[FILENAME_MAX];
 
@@ -130,13 +94,13 @@ static int elf_nsect, nsections;
 static int32_t elf_foffs;
 
 static void elf_write(void);
-static void elf_sect_write(struct Section *, const uint8_t *,
+static void elf_sect_write(struct elf_section *, const uint8_t *,
                            uint32_t);
 static void elf_section_header(int, int, int, void *, bool, int32_t, int, int,
                                int, int);
 static void elf_write_sections(void);
 static struct SAA *elf_build_symtab(int32_t *, int32_t *);
-static struct SAA *elf_build_reltab(int32_t *, struct Reloc *);
+static struct SAA *elf_build_reltab(uint64_t *, struct elf_reloc *);
 static void add_sectname(char *, char *);
 
 struct erel {
@@ -191,7 +155,7 @@ static int32_t dwarf_infosym, dwarf_abbrevsym, dwarf_linesym;
 
 static struct dfmt df_dwarf;
 static struct dfmt df_stabs;
-static struct Symbol *lastsym;
+static struct elf_symbol *lastsym;
 
 /* common debugging routines */
 static void debug32_typevalue(int32_t);
@@ -226,7 +190,7 @@ static void elf_init(void)
 {
     sects = NULL;
     nsects = sectlen = 0;
-    syms = saa_init((int32_t)sizeof(struct Symbol));
+    syms = saa_init((int32_t)sizeof(struct elf_symbol));
     nlocals = nglobs = ndebugs = 0;
     bsym = raa_init();
     strs = saa_init(1L);
@@ -257,7 +221,7 @@ static void elf_init(void)
 
 static void elf_cleanup(int debuginfo)
 {
-    struct Reloc *r;
+    struct elf_reloc *r;
     int i;
 
     (void)debuginfo;
@@ -295,7 +259,7 @@ static void add_sectname(char *firsthalf, char *secondhalf)
 
 static int elf_make_section(char *name, int type, int flags, int align)
 {
-    struct Section *s;
+    struct elf_section *s;
 
     s = nasm_zalloc(sizeof(*s));
 
@@ -383,7 +347,7 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
                          int is_global, char *special)
 {
     int pos = strslen;
-    struct Symbol *sym;
+    struct elf_symbol *sym;
     bool special_used = false;
 
 #if defined(DEBUG) && DEBUG>2
@@ -405,7 +369,7 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
     }
 
     if (is_global == 3) {
-        struct Symbol **s;
+        struct elf_symbol **s;
         /*
          * Fix up a forward-reference symbol size from the first
          * pass.
@@ -595,11 +559,11 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
         nasm_error(ERR_NONFATAL, "no special symbol features supported here");
 }
 
-static void elf_add_reloc(struct Section *sect, int32_t segment, int type)
+static void elf_add_reloc(struct elf_section *sect, int32_t segment, int type)
 {
-    struct Reloc *r;
+    struct elf_reloc *r;
 
-    r = *sect->tail = nasm_zalloc(sizeof(struct Reloc));
+    r = *sect->tail = nasm_zalloc(sizeof(struct elf_reloc));
     sect->tail = &r->next;
 
     r->address = sect->len;
@@ -638,13 +602,13 @@ static void elf_add_reloc(struct Section *sect, int32_t segment, int type)
  * Inefficiency: we search, currently, using a linked list which
  * isn't even necessarily sorted.
  */
-static int32_t elf_add_gsym_reloc(struct Section *sect,
+static int32_t elf_add_gsym_reloc(struct elf_section *sect,
                                int32_t segment, uint32_t offset,
                                int type, bool exact)
 {
-    struct Reloc *r;
-    struct Section *s;
-    struct Symbol *sym;
+    struct elf_reloc *r;
+    struct elf_section *s;
+    struct elf_symbol *sym;
     struct rbtree *srb;
     int i;
 
@@ -677,9 +641,9 @@ static int32_t elf_add_gsym_reloc(struct Section *sect,
                     " for this reference");
         return 0;
     }
-    sym = container_of(srb, struct Symbol, symv);
+    sym = container_of(srb, struct elf_symbol, symv);
 
-    r = *sect->tail = nasm_malloc(sizeof(struct Reloc));
+    r = *sect->tail = nasm_malloc(sizeof(struct elf_reloc));
     sect->tail = &r->next;
 
     r->next     = NULL;
@@ -696,7 +660,7 @@ static void elf_out(int32_t segto, const void *data,
                     enum out_type type, uint64_t size,
                     int32_t segment, int32_t wrt)
 {
-    struct Section *s;
+    struct elf_section *s;
     int32_t addr;
     uint8_t mydata[8], *p;
     int reltype, bytes;
@@ -1001,7 +965,7 @@ static void elf_write(void)
     for (i = 0; i < nsects; i++)
         if (sects[i]->head)
             sects[i]->rel = elf_build_reltab(&sects[i]->rellen,
-                                             sects[i]->head);
+					     sects[i]->head);
 
     /*
      * Now output the section header table.
@@ -1132,7 +1096,7 @@ static void elf_write(void)
 static struct SAA *elf_build_symtab(int32_t *len, int32_t *local)
 {
     struct SAA *s = saa_init(1L);
-    struct Symbol *sym;
+    struct elf_symbol *sym;
     uint8_t entry[16], *p;
     int i;
 
@@ -1251,7 +1215,7 @@ static struct SAA *elf_build_symtab(int32_t *len, int32_t *local)
     return s;
 }
 
-static struct SAA *elf_build_reltab(int32_t *len, struct Reloc *r)
+static struct SAA *elf_build_reltab(uint64_t *len, struct elf_reloc *r)
 {
     struct SAA *s;
     uint8_t *p, entry[8];
@@ -1327,7 +1291,7 @@ static void elf_write_sections(void)
         }
 }
 
-static void elf_sect_write(struct Section *sect,
+static void elf_sect_write(struct elf_section *sect,
                            const uint8_t *data, uint32_t len)
 {
     saa_wbytes(sect->data, data, len);
@@ -1336,7 +1300,7 @@ static void elf_sect_write(struct Section *sect,
 
 static void elf_sectalign(int32_t seg, unsigned int value)
 {
-    struct Section *s = NULL;
+    struct elf_section *s = NULL;
     int i;
 
     for (i = 0; i < nsects; i++) {
diff --git a/output/outelf64.c b/output/outelf64.c
index 537d3a5..0e6b6bc 100644
--- a/output/outelf64.c
+++ b/output/outelf64.c
@@ -60,46 +60,8 @@
 
 #ifdef OF_ELF64
 
-/*
- * Relocation types.
- */
-struct Reloc {
-    struct Reloc *next;
-    int64_t address;            /* relative to _start_ of section */
-    int64_t symbol;             /* symbol index */
-    int64_t offset;             /* symbol addend */
-    int type;                   /* type of relocation */
-};
-
-struct Symbol {
-    struct rbtree symv;         /* symbol value and rbtree of globals */
-    int32_t strpos;             /* string table position of name */
-    int32_t section;            /* section ID of the symbol */
-    int type;                   /* symbol type */
-    int other;                  /* symbol visibility */
-    int32_t size;               /* size of symbol */
-    int32_t globnum;            /* symbol table offset if global */
-    struct Symbol *nextfwd;     /* list of unresolved-size symbols */
-    char *name;                 /* used temporarily if in above list */
-};
-
-struct Section {
-    struct SAA *data;
-    uint64_t len, size;
-    uint32_t nrelocs;
-    int32_t index;              /* index into sects array */
-    int type;                   /* SHT_PROGBITS or SHT_NOBITS */
-    uint64_t align;             /* alignment: power of two */
-    uint64_t flags;             /* section flags */
-    char *name;
-    struct SAA *rel;
-    uint64_t rellen;
-    struct Reloc *head, **tail;
-    struct rbtree *gsyms;       /* global symbols in section */
-};
-
 #define SECT_DELTA 32
-static struct Section **sects;
+static struct elf_section **sects;
 static int nsects, sectlen;
 
 #define SHSTR_DELTA 256
@@ -116,7 +78,7 @@ static struct RAA *bsym;
 static struct SAA *strs;
 static uint32_t strslen;
 
-static struct Symbol *fwds;
+static struct elf_symbol *fwds;
 
 static char elf_module[FILENAME_MAX];
 
@@ -131,13 +93,13 @@ static int elf_nsect, nsections;
 static int64_t elf_foffs;
 
 static void elf_write(void);
-static void elf_sect_write(struct Section *, const void *, size_t);
-static void elf_sect_writeaddr(struct Section *, int64_t, size_t);
+static void elf_sect_write(struct elf_section *, const void *, size_t);
+static void elf_sect_writeaddr(struct elf_section *, int64_t, size_t);
 static void elf_section_header(int, int, uint64_t, void *, bool, uint64_t, int, int,
                                int, int);
 static void elf_write_sections(void);
 static struct SAA *elf_build_symtab(int32_t *, int32_t *);
-static struct SAA *elf_build_reltab(uint64_t *, struct Reloc *);
+static struct SAA *elf_build_reltab(uint64_t *, struct elf_reloc *);
 static void add_sectname(char *, char *);
 
 struct erel {
@@ -195,7 +157,7 @@ static int64_t dwarf_infosym, dwarf_abbrevsym, dwarf_linesym;
 
 static struct dfmt df_dwarf;
 static struct dfmt df_stabs;
-static struct Symbol *lastsym;
+static struct elf_symbol *lastsym;
 
 /* common debugging routines */
 static void debug64_typevalue(int32_t);
@@ -232,7 +194,7 @@ static void elf_init(void)
     maxbits = 64;
     sects = NULL;
     nsects = sectlen = 0;
-    syms = saa_init((int32_t)sizeof(struct Symbol));
+    syms = saa_init((int32_t)sizeof(struct elf_symbol));
     nlocals = nglobs = ndebugs = 0;
     bsym = raa_init();
     strs = saa_init(1L);
@@ -264,7 +226,7 @@ static void elf_init(void)
 
 static void elf_cleanup(int debuginfo)
 {
-    struct Reloc *r;
+    struct elf_reloc *r;
     int i;
 
     (void)debuginfo;
@@ -303,7 +265,7 @@ static void add_sectname(char *firsthalf, char *secondhalf)
 
 static int elf_make_section(char *name, int type, int flags, int align)
 {
-    struct Section *s;
+    struct elf_section *s;
 
     s = nasm_zalloc(sizeof(*s));
 
@@ -391,7 +353,7 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
                          int is_global, char *special)
 {
     int pos = strslen;
-    struct Symbol *sym;
+    struct elf_symbol *sym;
     bool special_used = false;
 
 #if defined(DEBUG) && DEBUG>2
@@ -413,7 +375,7 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
     }
 
     if (is_global == 3) {
-        struct Symbol **s;
+        struct elf_symbol **s;
         /*
          * Fix up a forward-reference symbol size from the first
          * pass.
@@ -603,12 +565,12 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
         nasm_error(ERR_NONFATAL, "no special symbol features supported here");
 }
 
-static void elf_add_reloc(struct Section *sect, int32_t segment,
+static void elf_add_reloc(struct elf_section *sect, int32_t segment,
                           int64_t offset, int type)
 {
-    struct Reloc *r;
+    struct elf_reloc *r;
 
-    r = *sect->tail = nasm_zalloc(sizeof(struct Reloc));
+    r = *sect->tail = nasm_zalloc(sizeof(struct elf_reloc));
     sect->tail = &r->next;
 
     r->address = sect->len;
@@ -649,13 +611,13 @@ static void elf_add_reloc(struct Section *sect, int32_t segment,
  * Inefficiency: we search, currently, using a linked list which
  * isn't even necessarily sorted.
  */
-static void elf_add_gsym_reloc(struct Section *sect,
+static void elf_add_gsym_reloc(struct elf_section *sect,
                                int32_t segment, uint64_t offset, int64_t pcrel,
                                int type, bool exact)
 {
-    struct Reloc *r;
-    struct Section *s;
-    struct Symbol *sym;
+    struct elf_reloc *r;
+    struct elf_section *s;
+    struct elf_symbol *sym;
     struct rbtree *srb;
     int i;
 
@@ -687,9 +649,9 @@ static void elf_add_gsym_reloc(struct Section *sect,
               " for this reference");
         return;
     }
-    sym = container_of(srb, struct Symbol, symv);
+    sym = container_of(srb, struct elf_symbol, symv);
 
-    r = *sect->tail = nasm_malloc(sizeof(struct Reloc));
+    r = *sect->tail = nasm_malloc(sizeof(struct elf_reloc));
     sect->tail = &r->next;
     r->next = NULL;
 
@@ -705,7 +667,7 @@ static void elf_out(int32_t segto, const void *data,
                     enum out_type type, uint64_t size,
                     int32_t segment, int32_t wrt)
 {
-    struct Section *s;
+    struct elf_section *s;
     int64_t addr;
     int reltype, bytes;
     int i;
@@ -1220,7 +1182,7 @@ static void elf_write(void)
 static struct SAA *elf_build_symtab(int32_t *len, int32_t *local)
 {
     struct SAA *s = saa_init(1L);
-    struct Symbol *sym;
+    struct elf_symbol *sym;
     uint8_t entry[24], *p;
     int i;
 
@@ -1339,7 +1301,7 @@ static struct SAA *elf_build_symtab(int32_t *len, int32_t *local)
     return s;
 }
 
-static struct SAA *elf_build_reltab(uint64_t *len, struct Reloc *r)
+static struct SAA *elf_build_reltab(uint64_t *len, struct elf_reloc *r)
 {
     struct SAA *s;
     uint8_t *p, entry[24];
@@ -1417,13 +1379,13 @@ static void elf_write_sections(void)
         }
 }
 
-static void elf_sect_write(struct Section *sect, const void *data, size_t len)
+static void elf_sect_write(struct elf_section *sect, const void *data, size_t len)
 {
     saa_wbytes(sect->data, data, len);
     sect->len += len;
 }
 
-static void elf_sect_writeaddr(struct Section *sect, int64_t data, size_t len)
+static void elf_sect_writeaddr(struct elf_section *sect, int64_t data, size_t len)
 {
     saa_writeaddr(sect->data, data, len);
     sect->len += len;
@@ -1431,7 +1393,7 @@ static void elf_sect_writeaddr(struct Section *sect, int64_t data, size_t len)
 
 static void elf_sectalign(int32_t seg, unsigned int value)
 {
-    struct Section *s = NULL;
+    struct elf_section *s = NULL;
     int i;
 
     for (i = 0; i < nsects; i++) {
diff --git a/output/outelfx32.c b/output/outelfx32.c
index ccb022d..6b352a2 100644
--- a/output/outelfx32.c
+++ b/output/outelfx32.c
@@ -60,45 +60,8 @@
 
 #ifdef OF_ELFX32
 
-/*
- * Relocation types.
- */
-struct Reloc {
-    struct Reloc *next;
-    int32_t address;            /* relative to _start_ of section */
-    int32_t symbol;             /* symbol index */
-    int32_t offset;             /* symbol addend */
-    int type;                   /* type of relocation */
-};
-
-struct Symbol {
-    struct rbtree symv;         /* symbol value and rbtree of globals */
-    int32_t strpos;             /* string table position of name */
-    int32_t section;            /* section ID of the symbol */
-    int type;                   /* symbol type */
-    int other;                  /* symbol visibility */
-    int32_t size;               /* size of symbol */
-    int32_t globnum;            /* symbol table offset if global */
-    struct Symbol *nextfwd;     /* list of unresolved-size symbols */
-    char *name;                 /* used temporarily if in above list */
-};
-
-struct Section {
-    struct SAA *data;
-    uint32_t len, size, nrelocs;
-    int32_t index;              /* index into sects array */
-    int type;                   /* SHT_PROGBITS or SHT_NOBITS */
-    uint32_t align;             /* alignment: power of two */
-    uint32_t flags;             /* section flags */
-    char *name;
-    struct SAA *rel;
-    uint32_t rellen;
-    struct Reloc *head, **tail;
-    struct rbtree *gsyms;       /* global symbols in section */
-};
-
 #define SECT_DELTA 32
-static struct Section **sects;
+static struct elf_section **sects;
 static int nsects, sectlen;
 
 #define SHSTR_DELTA 256
@@ -115,7 +78,7 @@ static struct RAA *bsym;
 static struct SAA *strs;
 static uint32_t strslen;
 
-static struct Symbol *fwds;
+static struct elf_symbol *fwds;
 
 static char elf_module[FILENAME_MAX];
 
@@ -130,13 +93,13 @@ static int elf_nsect, nsections;
 static int32_t elf_foffs;
 
 static void elf_write(void);
-static void elf_sect_write(struct Section *, const void *, size_t);
-static void elf_sect_writeaddr(struct Section *, int32_t, size_t);
+static void elf_sect_write(struct elf_section *, const void *, size_t);
+static void elf_sect_writeaddr(struct elf_section *, int32_t, size_t);
 static void elf_section_header(int, int, uint32_t, void *, bool, uint32_t, int, int,
                                int, int);
 static void elf_write_sections(void);
 static struct SAA *elf_build_symtab(int32_t *, int32_t *);
-static struct SAA *elf_build_reltab(uint32_t *, struct Reloc *);
+static struct SAA *elf_build_reltab(uint64_t *, struct elf_reloc *);
 static void add_sectname(char *, char *);
 
 struct erel {
@@ -193,7 +156,7 @@ static int32_t dwarf_infosym, dwarf_abbrevsym, dwarf_linesym;
 
 static struct dfmt df_dwarf;
 static struct dfmt df_stabs;
-static struct Symbol *lastsym;
+static struct elf_symbol *lastsym;
 
 /* common debugging routines */
 static void debugx32_typevalue(int32_t);
@@ -230,7 +193,7 @@ static void elf_init(void)
     maxbits = 64;
     sects = NULL;
     nsects = sectlen = 0;
-    syms = saa_init((int32_t)sizeof(struct Symbol));
+    syms = saa_init((int32_t)sizeof(struct elf_symbol));
     nlocals = nglobs = ndebugs = 0;
     bsym = raa_init();
     strs = saa_init(1L);
@@ -262,7 +225,7 @@ static void elf_init(void)
 
 static void elf_cleanup(int debuginfo)
 {
-    struct Reloc *r;
+    struct elf_reloc *r;
     int i;
 
     (void)debuginfo;
@@ -301,7 +264,7 @@ static void add_sectname(char *firsthalf, char *secondhalf)
 
 static int elf_make_section(char *name, int type, int flags, int align)
 {
-    struct Section *s;
+    struct elf_section *s;
 
     s = nasm_zalloc(sizeof(*s));
 
@@ -389,7 +352,7 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
                          int is_global, char *special)
 {
     int pos = strslen;
-    struct Symbol *sym;
+    struct elf_symbol *sym;
     bool special_used = false;
 
 #if defined(DEBUG) && DEBUG>2
@@ -411,7 +374,7 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
     }
 
     if (is_global == 3) {
-        struct Symbol **s;
+        struct elf_symbol **s;
         /*
          * Fix up a forward-reference symbol size from the first
          * pass.
@@ -601,12 +564,12 @@ static void elf_deflabel(char *name, int32_t segment, int64_t offset,
         nasm_error(ERR_NONFATAL, "no special symbol features supported here");
 }
 
-static void elf_add_reloc(struct Section *sect, int32_t segment,
+static void elf_add_reloc(struct elf_section *sect, int32_t segment,
                           int32_t offset, int type)
 {
-    struct Reloc *r;
+    struct elf_reloc *r;
 
-    r = *sect->tail = nasm_zalloc(sizeof(struct Reloc));
+    r = *sect->tail = nasm_zalloc(sizeof(struct elf_reloc));
     sect->tail = &r->next;
 
     r->address = sect->len;
@@ -647,13 +610,13 @@ static void elf_add_reloc(struct Section *sect, int32_t segment,
  * Inefficiency: we search, currently, using a linked list which
  * isn't even necessarily sorted.
  */
-static void elf_add_gsym_reloc(struct Section *sect,
+static void elf_add_gsym_reloc(struct elf_section *sect,
                                int32_t segment, uint32_t offset, int32_t pcrel,
                                int type, bool exact)
 {
-    struct Reloc *r;
-    struct Section *s;
-    struct Symbol *sym;
+    struct elf_reloc *r;
+    struct elf_section *s;
+    struct elf_symbol *sym;
     struct rbtree *srb;
     int i;
 
@@ -685,9 +648,9 @@ static void elf_add_gsym_reloc(struct Section *sect,
               " for this reference");
         return;
     }
-    sym = container_of(srb, struct Symbol, symv);
+    sym = container_of(srb, struct elf_symbol, symv);
 
-    r = *sect->tail = nasm_malloc(sizeof(struct Reloc));
+    r = *sect->tail = nasm_malloc(sizeof(struct elf_reloc));
     sect->tail = &r->next;
     r->next = NULL;
 
@@ -703,7 +666,7 @@ static void elf_out(int32_t segto, const void *data,
                     enum out_type type, uint64_t size,
                     int32_t segment, int32_t wrt)
 {
-    struct Section *s;
+    struct elf_section *s;
     int32_t addr;
     int reltype, bytes;
     int i;
@@ -1180,7 +1143,7 @@ static void elf_write(void)
 static struct SAA *elf_build_symtab(int32_t *len, int32_t *local)
 {
     struct SAA *s = saa_init(1L);
-    struct Symbol *sym;
+    struct elf_symbol *sym;
     uint8_t entry[24], *p;
     int i;
 
@@ -1299,7 +1262,7 @@ static struct SAA *elf_build_symtab(int32_t *len, int32_t *local)
     return s;
 }
 
-static struct SAA *elf_build_reltab(uint32_t *len, struct Reloc *r)
+static struct SAA *elf_build_reltab(uint64_t *len, struct elf_reloc *r)
 {
     struct SAA *s;
     uint8_t *p, entry[12];
@@ -1376,12 +1339,12 @@ static void elf_write_sections(void)
         }
 }
 
-static void elf_sect_write(struct Section *sect, const void *data, size_t len)
+static void elf_sect_write(struct elf_section *sect, const void *data, size_t len)
 {
     saa_wbytes(sect->data, data, len);
     sect->len += len;
 }
-static void elf_sect_writeaddr(struct Section *sect, int32_t data, size_t len)
+static void elf_sect_writeaddr(struct elf_section *sect, int32_t data, size_t len)
 {
     saa_writeaddr(sect->data, data, len);
     sect->len += len;
@@ -1389,7 +1352,7 @@ static void elf_sect_writeaddr(struct Section *sect, int32_t data, size_t len)
 
 static void elf_sectalign(int32_t seg, unsigned int value)
 {
-    struct Section *s = NULL;
+    struct elf_section *s = NULL;
     int i;
 
     for (i = 0; i < nsects; i++) {
-- 
1.9.3

[Nasm-devel] [PATCH 1/2] output: elf -- Move common structures into outelf.h header

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

All Elf formats we're supporting at the moment have
are using same structures, move them into a header
and name then with elf_ prefix.

This makes a few fields to carry 64 bit integers while
in former Elf32|x formats they can be 32 bit wide, but
I think it's acceptable tradeoff.

Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---
 output/outelf.h | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/output/outelf.h b/output/outelf.h
index 6267721..4d6db5d 100644
--- a/output/outelf.h
+++ b/output/outelf.h
@@ -38,6 +38,8 @@
 #define OUTPUT_OUTELF_H
 
 #include "output/elf.h"
+#include "rbtree.h"
+#include "saa.h"
 
 /* symbol binding */
 #define SYM_GLOBAL      ELF32_ST_MKBIND(STB_GLOBAL)
@@ -118,4 +120,41 @@ void elf_section_attrib(char *name, char *attr, int pass,
         WRITELONG(p, n_value);                              \
     } while (0)
 
+struct elf_reloc {
+    struct elf_reloc    *next;
+    int64_t             address;        /* relative to _start_ of section */
+    int64_t             symbol;         /* symbol index */
+    int64_t             offset;         /* symbol addend */
+    int                 type;           /* type of relocation */
+};
+
+struct elf_symbol {
+    struct rbtree       symv;           /* symbol value and symbol rbtree */
+    int32_t             strpos;         /* string table position of name */
+    int32_t             section;        /* section ID of the symbol */
+    int                 type;           /* symbol type */
+    int                 other;          /* symbol visibility */
+    int32_t             size;           /* size of symbol */
+    int32_t             globnum;        /* symbol table offset if global */
+    struct elf_symbol   *nextfwd;       /* list of unresolved-size symbols */
+    char                *name;          /* used temporarily if in above list */
+};
+
+struct elf_section {
+    struct SAA          *data;
+    uint64_t            len;
+    uint64_t            size;
+    uint64_t            nrelocs;
+    int32_t             index;
+    int                 type;           /* SHT_PROGBITS or SHT_NOBITS */
+    uint64_t            align;          /* alignment: power of two */
+    uint64_t            flags;          /* section flags */
+    char                *name;
+    struct SAA          *rel;
+    uint64_t             rellen;
+    struct elf_reloc    *head;
+    struct elf_reloc    **tail;
+    struct rbtree       *gsyms;         /* global symbols in section */
+};
+
 #endif /* OUTPUT_OUTELF_H */
-- 
1.9.3

[Nasm-devel] [PATCH 0/2] Elf: Start code unification

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

We've a number of files which almost copy/pasted for Elf32/32x/64
output formats, so when time permits I'm working on this code unification.
The final idea is to have a single Elf engine.

While been able to build nasm with gcc I would like to hear your
opinion on idea and if possible try to build nasm with patch applied
on other platforms.

Cyrill Gorcunov (2):
  output: elf -- Move common structures into outelf.h header
  output: elf -- Use common elf_ structures

 output/outelf.h    | 39 +++++++++++++++++++++++
 output/outelf32.c  | 86 +++++++++++++++------------------------------------
 output/outelf64.c  | 90 ++++++++++++++++--------------------------------------
 output/outelfx32.c | 89 ++++++++++++++++-------------------------------------
 4 files changed, 116 insertions(+), 188 deletions(-)

-- 
1.9.3

Re: [Nasm-devel] Question from the forum

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

On 08/29/2014 12:09 PM, Frank Kotler wrote:
> Hi list,
> 
> There's a guy on the forum...
> 
> http://forum.nasm.us/index.php?topic=1960.new;topicseen#new
> 
> trying to build Nasm from source using VC++2005 or VS6 or such. He has 
> asked what tools we use to build the pre-built version of Windows, and 
> the Makefile. He seems to suspect that I'm refusing to tell him, but I 
> don't know. OpenWatcom, at one point, wasn't it? If anyone has a minute 
> to take a look and help the guy out, it'd be appreciated. (or I can pass 
> a message on)
> 
> Best,
> Frank
> 

We use MinGW-W64 on hosted on Linux (because our build server is a Linux
box.)

A reasonably modern MSVC++ should work, but the one he is using is ancient.

	-hpa

[Nasm-devel] Question from the forum

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

Hi list,

There's a guy on the forum...

http://forum.nasm.us/index.php?topic=1960.new;topicseen#new

trying to build Nasm from source using VC++2005 or VS6 or such. He has 
asked what tools we use to build the pre-built version of Windows, and 
the Makefile. He seems to suspect that I'm refusing to tell him, but I 
don't know. OpenWatcom, at one point, wasn't it? If anyone has a minute 
to take a look and help the guy out, it'd be appreciated. (or I can pass 
a message on)

Best,
Frank

[Nasm-devel] Question about jobs

[hackOS s. <0xh...@gm...>]

Hello,

ok so i a have a general question about the developpement of NASM.

I like NASM very much, but i don't have any idea what company use it.

So i can use NASM only for fun, like wrote operating system only in asm
intel and that is my problem, i would like to know what is the job use NASM.


Thanks.

PS: I'm french

Re: [Nasm-devel] introduction

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

On 08/09/2014 08:19 AM, suresh babu wrote:
> Hi jim,
> 
> Do you want to make nasm more optimized for Intel?
> 
> regards,
> sureshbk.
> 

Jim is largely going to be taking over for the work that Jin has been
doing -- adding support for new instructions and hopefully new features.

	-hpa

Re: [Nasm-devel] introduction

[suresh b. <k_s...@ya...>]

Hi jim,

Do you want to make nasm more optimized for Intel?

regards,
sureshbk.



On Friday, August 8, 2014 11:49 AM, Frank Kotler <fbk...@my...> wrote:
 


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

Hi Jim,

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

Best,
Frank




------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Nasm-devel mailing list
Nas...@li...
https://lists.sourceforge.net/lists/listinfo/nasm-devel