nasm-devel — NASM development work

Re: [Nasm-devel] NASM 2.12.03rc1

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

also, all the

  code line longer than 68 chars: ...

warnings might as well be silenced

they just clutter the output

Re: [Nasm-devel] NASM 2.12.03rc1

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

On 10/4/16, H. Peter Anvin <hp...@zy...> wrote:
> Hi all,
>
> I have tagged a NASM 2.12.03rc1.  I hope to get a 2.12.03 out as soon as
> possible.  Please let me know if there is anything missing, or broken.

build fails on OS X as follows:

[starting from a blank slate]

$ git clone git://repo.or.cz/nasm.git nasm

$ cd nasm

$ sh autogen.sh

$ sh configure

$ make alldeps
[...]
tools/mkdep.pl: cannot determine path for dependency:
include/compiler.h -> config/config.h
make: *** [alldeps] Error 25

$ make
make: *** No rule to make target `config.h', needed by `asm/nasm.o'.  Stop.

$ ls config/
config.h	config.h.in	msvc.h		unknown.h

$ ls include/
compiler.h	hashtbl.h	insns.h		md5.h		nasmint.h	opflags.h	rbtree.h	saa.h		tables.h
disp8.h		iflag.h		labels.h	nasm.h		nasmlib.h	raa.h		rdoff.h		strlist.h	ver.h

do the dependencies actually change frequently enough
to warrant this overly complicated auto generation?

Re: [Nasm-devel] NASM 2.12.03rc1

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

> If there are any errors while linking, there must not be an
> output file.

Is this actually the desired behavior? I note that gcc doesn't have
this behavior: If an error occurs during a compile, the old .o file is
left intact.

b

Re: [Nasm-devel] NASM 2.12.03rc1

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

>> Is this actually the desired behavior? I note that gcc doesn't have
>> this behavior: If an error occurs during a compile, the old .o file
>> is left intact.
> 
> Well, there really isn't a good portable way to do that, and it is
> consistent with how NASM itself operates.

Fair enough.

b

Re: [Nasm-devel] NASM 2.12.03rc1

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

On October 4, 2016 11:30:53 AM PDT, Brian Raiter <bre...@mu...> wrote:
>> If there are any errors while linking, there must not be an
>> output file.
>
>Is this actually the desired behavior? I note that gcc doesn't have
>this behavior: If an error occurs during a compile, the old .o file is
>left intact.
>
>b

Well, there really isn't a good portable way to do that, and it is consistent with how NASM itself operates.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [Nasm-devel] NASM 2.12.03rc1

[Daniel L. <da...@ma...>]

> On 4 Oct 2016, at 10:45, H. Peter Anvin <hp...@zy...> wrote:
> 
> On 10/04/16 00:33, Daniel Lundqvist wrote:
>> Hi,
>> 
>>> On 4 Oct 2016, at 09:14, H. Peter Anvin <hp...@zy...> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have tagged a NASM 2.12.03rc1.  I hope to get a 2.12.03 out as soon as
>>> possible.  Please let me know if there is anything missing, or broken.
>> 
>> If possible I would like to have the attached patch part of the release. I understand if it's too late for it though.
>> 
>> Also, if it can be improved let me know.
>> 
>>> 	-hpa
>> 
> 
> You shouldn't include <unistd.h>; and instead of using unlink() use the
> C standard function remove() [which does exactly the same thing, except
> it is defined in <stdio.h>].

Thank you for the quick feedback. Here is an updated patch.

-- 
daniel

Re: [Nasm-devel] NASM 2.12.03rc1

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

On 10/04/16 00:33, Daniel Lundqvist wrote:
> Hi,
> 
>> On 4 Oct 2016, at 09:14, H. Peter Anvin <hp...@zy...> wrote:
>>
>> Hi all,
>>
>> I have tagged a NASM 2.12.03rc1.  I hope to get a 2.12.03 out as soon as
>> possible.  Please let me know if there is anything missing, or broken.
> 
> If possible I would like to have the attached patch part of the release. I understand if it's too late for it though.
> 
> Also, if it can be improved let me know.
> 
>> 	-hpa
> 

You shouldn't include <unistd.h>; and instead of using unlink() use the
C standard function remove() [which does exactly the same thing, except
it is defined in <stdio.h>].

	hpa

Re: [Nasm-devel] NASM 2.12.03rc1

[Daniel L. <da...@ma...>]

Hi,

> On 4 Oct 2016, at 09:14, H. Peter Anvin <hp...@zy...> wrote:
> 
> Hi all,
> 
> I have tagged a NASM 2.12.03rc1.  I hope to get a 2.12.03 out as soon as
> possible.  Please let me know if there is anything missing, or broken.

If possible I would like to have the attached patch part of the release. I understand if it's too late for it though.

Also, if it can be improved let me know.

> 	-hpa

-- 
daniel

[Nasm-devel] NASM 2.12.03rc1

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

Hi all,

I have tagged a NASM 2.12.03rc1.  I hope to get a 2.12.03 out as soon as
possible.  Please let me know if there is anything missing, or broken.

	-hpa

Re: [Nasm-devel] add --version support

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

On Mon, Sep 12, 2016 at 02:09:35PM -0600, Andy Willis wrote:
> Hello,
> 
> Support for --v was added sometime back... I would also request --version:
> 

Pushed into repo. Thanks!

Re: [Nasm-devel] PATCH: Memory leaks.

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

On 09/07/16 05:47, Knut St. Osmundsen wrote:
> Hi!
> 
> 
> Attached are patches for four memory leaks in nasm-2.12.xx.
> 
> Signed-off-by: Knut St. Osmundsen <bir...@an...>
> 
> 
> Kind Regards,
> 
>  bird.
> 

For perm_alloc() the int should be size_t.

	-hpa

Re: [Nasm-devel] add --version support

[Andy W. <abw...@gm...>]

Cyrill Gorcunov wrote:
> On Mon, Sep 12, 2016 at 02:09:35PM -0600, Andy Willis wrote:
>> Hello,
>>
>> Support for --v was added sometime back... I would also request --version:
>
> No objections from me obviously. May I add your
>
> Signed-off-by: Andy Willis <abw...@gm...>
>
Yes.

Thank you.

Andy

Re: [Nasm-devel] add --version support

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

On Mon, Sep 12, 2016 at 02:09:35PM -0600, Andy Willis wrote:
> Hello,
> 
> Support for --v was added sometime back... I would also request --version:

No objections from me obviously. May I add your

Signed-off-by: Andy Willis <abw...@gm...>

[Nasm-devel] add --version support

[Andy W. <abw...@gm...>]

Hello,

Support for --v was added sometime back... I would also request --version:

diff --git a/asm/nasm.c b/asm/nasm.c
index 927918c..0f16c60 100644
--- a/asm/nasm.c
+++ b/asm/nasm.c
@@ -951,6 +951,9 @@ set_warning:
                  if (!nasm_stricmp(p, "--v"))
                      show_version();

+                if (!nasm_stricmp(p, "--version"))
+                    show_version();
+
                  for (s = 0; textopts[s].label; s++) {
                      if (!nasm_stricmp(p + 2, textopts[s].label)) {
                          break;




Andy

[Nasm-devel] PATCH: Memory leaks.

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

Hi!


Attached are patches for four memory leaks in nasm-2.12.xx.

Signed-off-by: Knut St. Osmundsen <bir...@an...>


Kind Regards,

 bird.

Re: [Nasm-devel] [PATCH 2/2] elf: Generate SHT_RELA relocs for elfx32/elf64 stabs

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

On Tue, Aug 16, 2016 at 03:24:47PM +0300, Cyrill Gorcunov wrote:
> On Fri, Aug 12, 2016 at 2:23 AM, Fabian Giesen <fa...@ra...> wrote:
> > bump :)
> 
> Sorry for delay, will take a look.

Everything merged. Thanks a huge!

Re: [Nasm-devel] READ THIS IF YOU ARE BUILDING THE MASTER BRANCH

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

On 08/16/16 14:15, H. Peter Anvin wrote:
> On 08/02/16 09:33, H. Peter Anvin wrote:
>> If you build pull the master branch into a directory you have previously
>> done a build in:
>>
>> YOU MUST DO A "git clean -d -f", OR THE BUILD WILL BE BROKEN.
>>
>> Use "git clean -d -n" to make sure it won't delete any files you
>> actually care about.
>>
>> This is because files have moved around, but the build will pick up
>> obsolete generated files if they are present.
>>
> 
> Note:
> 
> "git clean -fdx" is even better, but before doing so, use
> "git clean -ndx" to make sure you don't delete something that you can't
> replace.
> 

Also, Cyrill just pointed out that the dependency generation script
broke when the source code was reorganized.  This has now been fixed.

	-hpa

Re: [Nasm-devel] READ THIS IF YOU ARE BUILDING THE MASTER BRANCH

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

On 08/02/16 09:33, H. Peter Anvin wrote:
> If you build pull the master branch into a directory you have previously
> done a build in:
> 
> YOU MUST DO A "git clean -d -f", OR THE BUILD WILL BE BROKEN.
> 
> Use "git clean -d -n" to make sure it won't delete any files you
> actually care about.
> 
> This is because files have moved around, but the build will pick up
> obsolete generated files if they are present.
> 

Note:

"git clean -fdx" is even better, but before doing so, use
"git clean -ndx" to make sure you don't delete something that you can't
replace.

	-hpa

Re: [Nasm-devel] [PATCH 2/2] elf: Generate SHT_RELA relocs for elfx32/elf64 stabs

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

On Fri, Aug 12, 2016 at 2:23 AM, Fabian Giesen <fa...@ra...> wrote:
> bump :)
>

Sorry for delay, will take a look.

Re: [Nasm-devel] [PATCH 2/2] elf: Generate SHT_RELA relocs for elfx32/elf64 stabs

[Fabian G. <fa...@ra...>]

bump :)

-Fabian

On 7/28/2016 11:41 PM, Fabian Giesen wrote:
> stabs is the default debug format and GNU gold dies with an assertion
> failure when it encounters a SHT_REL section in an x64 ELF file.
>
> Signed-off-by: Fabian Giesen <fa...@ra...>
> ---
>  output/outelf.c | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/output/outelf.c b/output/outelf.c
> index 15bc751..b9075a8 100644
> --- a/output/outelf.c
> +++ b/output/outelf.c
> @@ -1574,7 +1574,7 @@ static void elf_write(void)
>          /* in case the debug information is wanted, just add these three sections... */
>          add_sectname("", ".stab");
>          add_sectname("", ".stabstr");
> -        add_sectname(".rel", ".stab");
> +        add_sectname(is_elf32() ? ".rel" : ".rela", ".stab");
>      } else if (dfmt_is_dwarf()) {
>          /* the dwarf debug standard specifies the following ten sections,
>             not all of which are currently implemented,
> @@ -1737,8 +1737,13 @@ static void elf_write(void)
>              p += strlen(p) + 1;
>
>              /* link -> symtable  info -> section to refer to */
> -            elf_section_header(p - shstrtab, SHT_REL, 0, stabrelbuf, false,
> -                               stabrellen, sec_symtab, sec_stab, 4, is_elf64() ? 16 : 8);
> +            if (is_elf32()) {
> +                elf_section_header(p - shstrtab, SHT_REL, 0, stabrelbuf, false,
> +                                   stabrellen, sec_symtab, sec_stab, 4, 8);
> +            } else {
> +                elf_section_header(p - shstrtab, SHT_RELA, 0, stabrelbuf, false,
> +                                   stabrellen, sec_symtab, sec_stab, 4, is_elf64() ? 24 : 12);
> +            }
>              p += strlen(p) + 1;
>          }
>      } else if (dfmt_is_dwarf()) {
> @@ -2589,11 +2594,13 @@ static void stabs_generate(void)
>          } else if (is_elfx32()) {
>              WRITELONG(rptr, (sptr - sbuf) - 4);
>              WRITELONG(rptr, ((ptr->info.section + 2) << 8) | R_X86_64_32);
> +            WRITELONG(rptr, 0);
>          } else {
>              nasm_assert(is_elf64());
>              WRITEDLONG(rptr, (int64_t)(sptr - sbuf) - 4);
>              WRITELONG(rptr, R_X86_64_32);
>              WRITELONG(rptr, ptr->info.section + 2);
> +            WRITEDLONG(rptr, 0);
>          }
>          numstabs++;
>          currfile = mainfileindex;
> @@ -2640,6 +2647,7 @@ static void stabs_generate(void)
>                  /* relocation table entry */
>                  WRITELONG(rptr, (sptr - sbuf) - 4);
>                  WRITELONG(rptr, ((ptr->info.section + 2) << 8) | R_X86_64_32);
> +                WRITELONG(rptr, ptr->info.offset);
>              }
>
>              WRITE_STAB(sptr, 0, N_SLINE, 0, ptr->line, ptr->info.offset);
> @@ -2648,6 +2656,7 @@ static void stabs_generate(void)
>              /* relocation table entry */
>              WRITELONG(rptr, (sptr - sbuf) - 4);
>              WRITELONG(rptr, ((ptr->info.section + 2) << 8) | R_X86_64_32);
> +            WRITELONG(rptr, ptr->info.offset);
>
>              ptr = ptr->next;
>          }
> @@ -2668,6 +2677,7 @@ static void stabs_generate(void)
>                  WRITEDLONG(rptr, (int64_t)(sptr - sbuf) - 4);
>                  WRITELONG(rptr, R_X86_64_32);
>                  WRITELONG(rptr, ptr->info.section + 2);
> +                WRITEDLONG(rptr, ptr->info.offset);
>              }
>
>              WRITE_STAB(sptr, 0, N_SLINE, 0, ptr->line, ptr->info.offset);
> @@ -2677,6 +2687,7 @@ static void stabs_generate(void)
>              WRITEDLONG(rptr, (int64_t)(sptr - sbuf) - 4);
>              WRITELONG(rptr, R_X86_64_32);
>              WRITELONG(rptr, ptr->info.section + 2);
> +            WRITEDLONG(rptr, ptr->info.offset);
>
>              ptr = ptr->next;
>          }
>

Re: [Nasm-devel] build fails on OS/2

[Dave Y. <dav...@gm...>]

On 08/02/16 06:57 AM, anonymous coward wrote:
> [adjusting thread subject, to split this off into its own thread]
>
> On 8/1/16, Dave Yeo<dav...@gm...>  wrote:
>> >On 08/01/16 04:45 PM, H. Peter Anvin wrote:
>>> >>Reorganizing the source code certainly has both caused and exposed
>>> >>dependency issues.
>>> >>--
>> >
>> >I tried building trunk (freshly checked out) on OS/2. Dies here,

Build now succeeding after git clean -d -f
Thanks
Dave

Re: [Nasm-devel] build fails on OS X

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

On Tue, Aug 02, 2016 at 10:02:05AM -0700, H. Peter Anvin wrote:
> 
> It's a massive hammer, though, and almost always wrong.  Other than some
> serious low-level programming, the most legitimate use for it is when
> you have objects in an archive that will be needed by subsequently
> dlopen()'d objects.

Yeah, seems so. This option saved me a lot of time because I needed
a fast project prototype (and it's low level -- object files get
converted into binary stream which get used by another programs
then) -- so once things get semi-done I'll check if there a way
to drop this flag completely.

For same reason I proposed to try it, because it's fast to test
and figure out if it solve the problem or not.

Re: [Nasm-devel] build fails on OS X

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

On 08/02/16 09:51, Cyrill Gorcunov wrote:
> On Tue, Aug 02, 2016 at 09:48:11AM -0700, anonymous coward wrote:
>>> I think --whole-archive option needed for ld
>>
>> not supported under OS X, it seems -- the ld
>> man page doesn't have it, and there are hits
>> in web searches for this very topic
> 
> I hit the same problem in other project where i've been
> linking objects and archive file into executable. But
> since it's unsupported on osx, won't help. Thanks for
> trying!
> 

It's a massive hammer, though, and almost always wrong.  Other than some
serious low-level programming, the most legitimate use for it is when
you have objects in an archive that will be needed by subsequently
dlopen()'d objects.

	-hpa

Re: [Nasm-devel] build fails on OS X

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

> OK, I just checked in a (hopefully) workaround for this.

works -- thanks

Re: [Nasm-devel] build fails on OS X

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

On 08/02/16 09:48, Cyrill Gorcunov wrote:
> On Tue, Aug 02, 2016 at 09:37:15AM -0700, H. Peter Anvin wrote:
>> On 08/02/16 07:23, Cyrill Gorcunov wrote:
>>> On Tue, Aug 02, 2016 at 06:54:54AM -0700, anonymous coward wrote:
>>>>
>>>> I'm not sure what to try next -- nasmlib.a seems to contain the
>>>> symbol, but somehow ld fails?
>>>
>>> I think --whole-archive option needed for ld
>>>
>>
>> That would defeat the entire purpose with the library, though.
> 
> How? IIRC --whole-archive tells linker to look into all objects
> in archive instead of first one.

No, it always does that.  --whole-archive means "include all objects in
the archive in the final executable", regardless of if an object is
needed or not.  The whole point of the exercise was to reduce the size
of especially ndisasm by omitting objects it really doesn't need.

	-hpa