You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(71) |
Aug
(152) |
Sep
(123) |
Oct
(49) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
(37) |
May
(554) |
Jun
(301) |
Jul
(84) |
Aug
(39) |
Sep
(44) |
Oct
(99) |
Nov
(41) |
Dec
(52) |
2003 |
Jan
(15) |
Feb
(32) |
Mar
(19) |
Apr
(4) |
May
(8) |
Jun
(30) |
Jul
(122) |
Aug
(100) |
Sep
(120) |
Oct
(4) |
Nov
(39) |
Dec
(32) |
2004 |
Jan
(38) |
Feb
(87) |
Mar
(11) |
Apr
(23) |
May
(7) |
Jun
(6) |
Jul
(18) |
Aug
(2) |
Sep
(22) |
Oct
(2) |
Nov
(7) |
Dec
(48) |
2005 |
Jan
(74) |
Feb
(29) |
Mar
(28) |
Apr
(1) |
May
(24) |
Jun
(16) |
Jul
(9) |
Aug
(7) |
Sep
(69) |
Oct
(11) |
Nov
(13) |
Dec
(13) |
2006 |
Jan
(5) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(12) |
Jun
(12) |
Jul
(5) |
Aug
(1) |
Sep
(4) |
Oct
(61) |
Nov
(68) |
Dec
(46) |
2007 |
Jan
(16) |
Feb
(15) |
Mar
(46) |
Apr
(171) |
May
(78) |
Jun
(109) |
Jul
(61) |
Aug
(71) |
Sep
(189) |
Oct
(219) |
Nov
(162) |
Dec
(91) |
2008 |
Jan
(49) |
Feb
(41) |
Mar
(43) |
Apr
(31) |
May
(70) |
Jun
(98) |
Jul
(39) |
Aug
(8) |
Sep
(75) |
Oct
(47) |
Nov
(11) |
Dec
(17) |
2009 |
Jan
(9) |
Feb
(12) |
Mar
(8) |
Apr
(11) |
May
(27) |
Jun
(25) |
Jul
(161) |
Aug
(28) |
Sep
(66) |
Oct
(36) |
Nov
(49) |
Dec
(22) |
2010 |
Jan
(34) |
Feb
(20) |
Mar
(3) |
Apr
(12) |
May
(1) |
Jun
(10) |
Jul
(28) |
Aug
(98) |
Sep
(7) |
Oct
(25) |
Nov
(4) |
Dec
(9) |
2011 |
Jan
|
Feb
(12) |
Mar
(7) |
Apr
(16) |
May
(11) |
Jun
(59) |
Jul
(120) |
Aug
(7) |
Sep
(4) |
Oct
(5) |
Nov
(3) |
Dec
(2) |
2012 |
Jan
|
Feb
(6) |
Mar
(21) |
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
(5) |
Oct
(3) |
Nov
(6) |
Dec
(1) |
2013 |
Jan
|
Feb
(19) |
Mar
(10) |
Apr
|
May
(2) |
Jun
|
Jul
(7) |
Aug
(62) |
Sep
(14) |
Oct
(44) |
Nov
(38) |
Dec
(47) |
2014 |
Jan
(14) |
Feb
(1) |
Mar
(4) |
Apr
|
May
(20) |
Jun
|
Jul
|
Aug
(8) |
Sep
(6) |
Oct
(11) |
Nov
(9) |
Dec
(9) |
2015 |
Jan
(3) |
Feb
(2) |
Mar
(2) |
Apr
(3) |
May
(2) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(10) |
Dec
(2) |
2016 |
Jan
(12) |
Feb
(13) |
Mar
(9) |
Apr
(45) |
May
(9) |
Jun
(2) |
Jul
(15) |
Aug
(32) |
Sep
(6) |
Oct
(28) |
Nov
(1) |
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
(13) |
May
(8) |
Jun
(2) |
Jul
(3) |
Aug
(10) |
Sep
|
Oct
(2) |
Nov
|
Dec
(1) |
2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(7) |
May
|
Jun
(8) |
Jul
|
Aug
(8) |
Sep
(2) |
Oct
(2) |
Nov
(8) |
Dec
(6) |
2019 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2020 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Liam B. <lia...@gm...> - 2022-04-18 21:10:32
|
This addresses bug 3392797: https://bugzilla.nasm.us/show_bug.cgi?id=3392797 It adds a warning if you try to use an invalid "rel" mode in an address. For example, lea rbx, [rel values + rdi * 8] ; this now generates a warning, but continues to ; generate the same instructions as before (equivalent to next line) lea rbx, [values + rdi * 8] ; this is a valid mode, and does not generate a warning. If "default rel" is set, no warning is produced for: lea rbx, [values + rdi * 8] Initially, I put the warning alongside other warnings in process_ea(), but that results in them being displayed twice (process_ea() is called from calcsize() and gencode()) on the final pass. Thank you all for such a great assembler! Signed-off-by: Liam Bowen <Lia...@gm...> --- asm/assemble.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/asm/assemble.c b/asm/assemble.c index cd3f4693..dc5ee023 100644 --- a/asm/assemble.c +++ b/asm/assemble.c @@ -2264,6 +2264,17 @@ static void gencode(struct out_data *data, insn *ins) rfield, rflags, ins, eat, &errmsg)) nasm_nonfatal("%s", errmsg); + /* If RIP-relative, indexreg and scale must not be present: + * [basereg + indexreg*scale + displacement] + * https://bugzilla.nasm.us/show_bug.cgi?id=3392797 + */ + if (bits == 64 && (opy->eaflags & EAF_REL) && + ((opy->indexreg != -1) || (opy->scale != -1))) { + nasm_warn(WARN_OTHER | ERR_PASS2, + "invalid addressing mode: RIP-relative address " + "cannot contain index register or scale"); + } + p = bytes; *p++ = ea_data.modrm; if (ea_data.sib_present) -- 2.25.1 |
From: Marco <mva...@pr...> - 2021-05-03 21:48:17
|
Hi Cyrill, No hurries. I just wanted to know if Github PRs were OK. It can wait :) Best Regards, Marco ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, May 3, 2021 2:31 PM, Cyrill Gorcunov <gor...@gm...> wrote: > On Mon, May 03, 2021 at 08:59:14PM +0000, Marco via Nasm-devel wrote: > > > Hi nasm-devel, > > Recently I sent out a pull request adding support for DW_AT_comp_dir in > > elf files[0]. The motivation for this change is that it makes it easier to > > debug programs compiled with nasm if the path is also emitted in the elf > > files. > > Is the project accepting github pull requests? Should I instead send > > patches to this mailing list? > > Best Regards, > > Marco > > [0]: https://github.com/netwide-assembler/nasm/pull/9 > > Hi Marco! I saw the request but didn't manage to take a look on > due to other duties. I'm really sorry. Actually if you send them > via mailing list there are more chances they to be reviewed. But > no promises though. > > Nasm-devel mailing list > Nas...@li... > https://lists.sourceforge.net/lists/listinfo/nasm-devel |
From: Cyrill G. <gor...@gm...> - 2021-05-03 21:31:26
|
On Mon, May 03, 2021 at 08:59:14PM +0000, Marco via Nasm-devel wrote: > Hi nasm-devel, > Recently I sent out a pull request adding support for DW_AT_comp_dir in > elf files[0]. The motivation for this change is that it makes it easier to > debug programs compiled with nasm if the path is also emitted in the elf > files. > Is the project accepting github pull requests? Should I instead send > patches to this mailing list? > Best Regards, > Marco > [0]: https://github.com/netwide-assembler/nasm/pull/9 Hi Marco! I saw the request but didn't manage to take a look on due to other duties. I'm really sorry. Actually if you send them via mailing list there are more chances they to be reviewed. But no promises though. |
From: Marco <mva...@pr...> - 2021-05-03 20:59:38
|
Hi nasm-devel, Recently I sent out a pull request adding support for DW_AT_comp_dir in elf files[0]. The motivation for this change is that it makes it easier to debug programs compiled with nasm if the path is also emitted in the elf files. Is the project accepting github pull requests? Should I instead send patches to this mailing list? Best Regards, Marco [0]: https://github.com/netwide-assembler/nasm/pull/9 |
From: Joshua W. <jpe...@gm...> - 2020-01-20 15:19:26
|
On 1/14/20 2:11 PM, hp...@zy... wrote: > On January 14, 2020 11:51:44 AM PST, Joshua Watt <jpe...@gm...> wrote: >> On 1/13/20 7:34 PM, H. Peter Anvin wrote: >>> On 2020-01-13 10:44, Joshua Watt wrote: >>>> On 12/18/19 11:46 AM, Joshua Watt wrote: >>>>> Adds a command line option --debug-prefix-map that changes the way >> file >>>>> paths are encoded in debug information (similar to >> -fdebug-prefix-map in >>>>> GCC). This allows nasm to generate reproducible output regardless >> of the >>>>> location of the files. >>>> Ping? >>>> >>> I would prefer if this could be made into a set of %pragma debug >> options; that >>> way they can be specified either in a source file or on the command >> line. >> >> I can do that if you think it's better, but out of curiosity, what's >> the >> utility in being able to specify the prefix mapping in the source file? >> >> It seems like isn't very useful because a source file isn't going to be >> >> able to know the location where it is checkout out to correctly set the >> >> option? >> >>> -hpa >>> > Consider config.h or the equivalent. Ok, I finally got around to attempting to do the debug prefix map with a %pragma, but there is a problem that I found with this approach: The output backends are initialized before the pragma options are parsed. Most of the backends set the "module" name (the thing that needs to be remapped) at initialization, meaning that the remapping doesn't occur at all because it's needed before any pragma commands are parsed. It looks like you can specify pragma statements on the command line with --pragma, but this doesn't seem any better than a dedicated option (e.g. --debug-prefix-map), and might be confusing to have a pragma that only really works when specified on the command line and has no effect when specified in a source file? |
From: Joshua W. <jpe...@gm...> - 2020-01-14 19:51:56
|
On 1/13/20 7:34 PM, H. Peter Anvin wrote: > On 2020-01-13 10:44, Joshua Watt wrote: >> On 12/18/19 11:46 AM, Joshua Watt wrote: >>> Adds a command line option --debug-prefix-map that changes the way file >>> paths are encoded in debug information (similar to -fdebug-prefix-map in >>> GCC). This allows nasm to generate reproducible output regardless of the >>> location of the files. >> Ping? >> > I would prefer if this could be made into a set of %pragma debug options; that > way they can be specified either in a source file or on the command line. I can do that if you think it's better, but out of curiosity, what's the utility in being able to specify the prefix mapping in the source file? It seems like isn't very useful because a source file isn't going to be able to know the location where it is checkout out to correctly set the option? > > -hpa > |
From: Joshua W. <jpe...@gm...> - 2020-01-13 18:44:55
|
On 12/18/19 11:46 AM, Joshua Watt wrote: > Adds a command line option --debug-prefix-map that changes the way file > paths are encoded in debug information (similar to -fdebug-prefix-map in > GCC). This allows nasm to generate reproducible output regardless of the > location of the files. Ping? > > Joshua Watt (2): > stdlib: Add strlcat > Add --debug-prefix-map option > > Makefile.in | 2 +- > asm/nasm.c | 26 ++++++++++++++++++++++++- > configure.ac | 2 ++ > include/compiler.h | 4 ++++ > include/nasmlib.h | 9 +++++++++ > nasm.txt | 4 ++++ > nasmlib/filename.c | 20 +++++++++++++++++++ > output/outas86.c | 4 +++- > output/outcoff.c | 4 ++-- > output/outelf.c | 2 +- > output/outieee.c | 2 +- > output/outobj.c | 2 +- > stdlib/strlcat.c | 43 +++++++++++++++++++++++++++++++++++++++++ > test/elfdebugprefix.asm | 6 ++++++ > test/performtest.pl | 12 ++++++++++-- > 15 files changed, 132 insertions(+), 10 deletions(-) > create mode 100644 stdlib/strlcat.c > create mode 100644 test/elfdebugprefix.asm > |
From: Joshua W. <jpe...@gm...> - 2019-12-18 17:46:40
|
Adds strlcat which can be used to safely concatenate strings Signed-off-by: Joshua Watt <JPE...@gm...> --- Makefile.in | 2 +- configure.ac | 2 ++ include/compiler.h | 4 ++++ stdlib/strlcat.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 stdlib/strlcat.c diff --git a/Makefile.in b/Makefile.in index 68ec9d45..546be89b 100644 --- a/Makefile.in +++ b/Makefile.in @@ -96,7 +96,7 @@ NASM = asm/nasm.$(O) NDISASM = disasm/ndisasm.$(O) LIBOBJ = stdlib/snprintf.$(O) stdlib/vsnprintf.$(O) stdlib/strlcpy.$(O) \ - stdlib/strnlen.$(O) stdlib/strrchrnul.$(O) \ + stdlib/strnlen.$(O) stdlib/strrchrnul.$(O) stdlib/strlcat.$(O) \ \ nasmlib/ver.$(O) \ nasmlib/alloc.$(O) nasmlib/asprintf.$(O) nasmlib/errfile.$(O) \ diff --git a/configure.ac b/configure.ac index 600056da..7d4369e5 100644 --- a/configure.ac +++ b/configure.ac @@ -158,6 +158,7 @@ AC_CHECK_FUNCS([vsnprintf _vsnprintf]) AC_CHECK_FUNCS([snprintf _snprintf]) AC_CHECK_FUNCS([strlcpy]) AC_CHECK_FUNCS([strrchrnul]) +AC_CHECK_FUNCS([strlcat]) dnl These types are POSIX-specific, and Windows does it differently... AC_CHECK_TYPES([struct _stati64]) @@ -177,6 +178,7 @@ AC_CHECK_DECLS(strsep) AC_CHECK_DECLS(strlcpy) AC_CHECK_DECLS(strnlen) AC_CHECK_DECLS(strrchrnul) +AC_CHECK_DECLS(strlcat) dnl Check for missing types AC_TYPE_UINTPTR_T diff --git a/include/compiler.h b/include/compiler.h index 04cab173..e6abde52 100644 --- a/include/compiler.h +++ b/include/compiler.h @@ -168,6 +168,10 @@ size_t strlcpy(char *, const char *, size_t); char *strrchrnul(const char *, int); #endif +#if !defined(HAVE_STRLCAT) || !HAVE_DECL_STRLCAT +size_t strlcat(char *, const char *, size_t); +#endif + #ifndef __cplusplus /* C++ has false, true, bool as keywords */ # ifdef HAVE_STDBOOL_H # include <stdbool.h> diff --git a/stdlib/strlcat.c b/stdlib/strlcat.c new file mode 100644 index 00000000..7084d460 --- /dev/null +++ b/stdlib/strlcat.c @@ -0,0 +1,43 @@ +/* + * Copyright (c) 2019 Garmin Ltd. or its subsidiaries + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include "compiler.h" + +/* + * Concatenate src string to dest of size size. The destination buffer will + * have no more than size-1 character when the operation finishes. Always NUL + * terminates, unless size == 0 or dest has no NUL terminator. Returns + * strlen(initial dest) + strlen(src); if retval >= size, truncation occurred. + */ +#ifndef HAVE_STRLCAT + +size_t strlcat(char *dest, const char *src, size_t size) +{ + size_t n; + + /* find the NULL terminator in dest */ + for (n = 0; i < size && dest[n] != '\0'; n++) + ; + + /* destination was not NULL terminated. Return the initial size */ + if (n == size) + return size; + + return strlcpy(&dest[n], src, size - n) + n; +} + +#endif + -- 2.23.0 |
From: Joshua W. <jpe...@gm...> - 2019-12-18 17:46:39
|
Adds an option to remap file prefixes in output object files. This is analogous to the "-fdebug-prefix-map" option in GCC, and allows files to be built in a reproducible manner regardless of the build directory. Signed-off-by: Joshua Watt <JPE...@gm...> --- asm/nasm.c | 26 +++++++++++++++++++++++++- include/nasmlib.h | 9 +++++++++ nasm.txt | 4 ++++ nasmlib/filename.c | 20 ++++++++++++++++++++ output/outas86.c | 4 +++- output/outcoff.c | 4 ++-- output/outelf.c | 2 +- output/outieee.c | 2 +- output/outobj.c | 2 +- stdlib/strlcat.c | 2 +- test/elfdebugprefix.asm | 6 ++++++ test/performtest.pl | 12 ++++++++++-- 12 files changed, 83 insertions(+), 10 deletions(-) create mode 100644 test/elfdebugprefix.asm diff --git a/asm/nasm.c b/asm/nasm.c index a30831dc..08d2a2eb 100644 --- a/asm/nasm.c +++ b/asm/nasm.c @@ -861,7 +861,8 @@ enum text_options { OPT_LIMIT, OPT_KEEP_ALL, OPT_NO_LINE, - OPT_DEBUG + OPT_DEBUG, + OPT_DEBUG_PREFIX_MAP }; enum need_arg { ARG_NO, @@ -893,6 +894,7 @@ static const struct textargs textopts[] = { {"keep-all", OPT_KEEP_ALL, ARG_NO, 0}, {"no-line", OPT_NO_LINE, ARG_NO, 0}, {"debug", OPT_DEBUG, ARG_MAYBE, 0}, + {"debug-prefix-map", OPT_DEBUG_PREFIX_MAP, true, 0}, {NULL, OPT_BOGUS, ARG_NO, 0} }; @@ -1255,6 +1257,26 @@ static bool process_arg(char *p, char *q, int pass) case OPT_DEBUG: debug_nasm = param ? strtoul(param, NULL, 10) : debug_nasm+1; break; + case OPT_DEBUG_PREFIX_MAP: { + struct debug_prefix_list *d; + char *c; + c = strchr(param, '='); + + if (!c) { + nasm_error(ERR_NONFATAL | ERR_NOFILE | ERR_USAGE, + "option `--%s' must be of the form `BASE=DEST'", p); + break; + } + + *c = '\0'; + d = nasm_malloc(sizeof(*d)); + d->next = debug_prefixes; + d->base = nasm_strdup(param); + d->dest = nasm_strdup(c + 1); + debug_prefixes = d; + *c = '='; + } + break; case OPT_HELP: help(stdout); exit(0); @@ -2098,6 +2120,8 @@ static void help(FILE *out) " -w-x disable warning x (also -Wno-x)\n" " -w[+-]error promote all warnings to errors (also -Werror)\n" " -w[+-]error=x promote warning x to errors (also -Werror=x)\n" + " --debug-prefix-map base=dest\n" + " remap paths starting with 'base' to 'dest' in output files\n" , out); fprintf(out, " %-20s %s\n", diff --git a/include/nasmlib.h b/include/nasmlib.h index 940f1cb7..830e9f61 100644 --- a/include/nasmlib.h +++ b/include/nasmlib.h @@ -250,10 +250,19 @@ int64_t readstrnum(char *str, int length, bool *warn); */ int32_t seg_alloc(void); +struct debug_prefix_list { + struct debug_prefix_list *next; + char *base; + char *dest; +}; + +extern struct debug_prefix_list *debug_prefixes; + /* * Add/replace or remove an extension to the end of a filename */ const char *filename_set_extension(const char *inname, const char *extension); +char *filename_debug_remap(char *dest, char const *inname, size_t len); /* * Utility macros... diff --git a/nasm.txt b/nasm.txt index cc7fa27b..d3485c99 100644 --- a/nasm.txt +++ b/nasm.txt @@ -147,6 +147,10 @@ OPTIONS Prepend or append (respectively) the given argument to all global or extern variables. +--debug-prefix-map 'BASE=DEST':: + Map file names beginning with 'BASE' to 'DEST' when encoding them in + output object files. + SYNTAX ------ This man page does not fully describe the syntax of *nasm*'s assembly language, diff --git a/nasmlib/filename.c b/nasmlib/filename.c index 172ae0bc..fda2be41 100644 --- a/nasmlib/filename.c +++ b/nasmlib/filename.c @@ -39,6 +39,8 @@ #include "nasmlib.h" #include "error.h" +struct debug_prefix_list *debug_prefixes = NULL; + /* * Add/modify a filename extension, assumed to be a period-delimited * field at the very end of the filename. Returns a newly allocated @@ -61,3 +63,21 @@ const char *filename_set_extension(const char *inname, const char *extension) return p; } + +char *filename_debug_remap(char *dest, char const *in, size_t len) +{ + struct debug_prefix_list *d; + size_t n; + + for (d = debug_prefixes; d != NULL; d = d->next) { + n = strlen(d->base); + if (strncmp(in, d->base, n) == 0) { + strlcpy(dest, d->dest, len); + strlcat(dest, &in[n], len); + return dest; + } + } + + strlcpy(dest, in, len); + return dest; +} diff --git a/output/outas86.c b/output/outas86.c index 54b22f87..c4a412c1 100644 --- a/output/outas86.c +++ b/output/outas86.c @@ -110,6 +110,8 @@ static void as86_sect_write(struct Section *, const uint8_t *, static void as86_init(void) { + char filename[FILENAME_MAX]; + stext.data = saa_init(1L); stext.datalen = 0L; stext.head = stext.last = NULL; @@ -131,7 +133,7 @@ static void as86_init(void) strslen = 0; /* as86 module name = input file minus extension */ - as86_add_string(filename_set_extension(inname, "")); + as86_add_string(filename_debug_remap(filename, filename_set_extension(inname, ""), sizeof(filename))); } static void as86_cleanup(void) diff --git a/output/outcoff.c b/output/outcoff.c index 60b7fdf8..581e5b7e 100644 --- a/output/outcoff.c +++ b/output/outcoff.c @@ -1062,14 +1062,14 @@ static void coff_symbol(char *name, int32_t strpos, int32_t value, static void coff_write_symbols(void) { - char filename[18]; + char filename[19]; uint32_t i; /* * The `.file' record, and the file name auxiliary record. */ coff_symbol(".file", 0L, 0L, -2, 0, 0x67, 1); - strncpy(filename, inname, 18); + filename_debug_remap(filename, inname, 19); nasm_write(filename, 18, ofile); /* diff --git a/output/outelf.c b/output/outelf.c index 4976b680..024246ae 100644 --- a/output/outelf.c +++ b/output/outelf.c @@ -528,7 +528,7 @@ static void elf_init(void) }; const char * const *p; - strlcpy(elf_module, inname, sizeof(elf_module)); + filename_debug_remap(elf_module, inname, sizeof(elf_module)); sects = NULL; nsects = sectlen = 0; syms = saa_init((int32_t)sizeof(struct elf_symbol)); diff --git a/output/outieee.c b/output/outieee.c index 4cc0f0f5..2468724b 100644 --- a/output/outieee.c +++ b/output/outieee.c @@ -207,7 +207,7 @@ static void ieee_unqualified_name(char *, char *); */ static void ieee_init(void) { - strlcpy(ieee_infile, inname, sizeof(ieee_infile)); + filename_debug_remap(ieee_infile, inname, sizeof(ieee_infile)); any_segs = false; fpubhead = NULL; fpubtail = &fpubhead; diff --git a/output/outobj.c b/output/outobj.c index 9d5e4b6a..fac67123 100644 --- a/output/outobj.c +++ b/output/outobj.c @@ -638,7 +638,7 @@ static enum directive_result obj_directive(enum directive, char *); static void obj_init(void) { - strlcpy(obj_infile, inname, sizeof(obj_infile)); + filename_debug_remap(obj_infile, inname, sizeof(obj_infile)); first_seg = seg_alloc(); any_segs = false; fpubhead = NULL; diff --git a/stdlib/strlcat.c b/stdlib/strlcat.c index 7084d460..ee93dea3 100644 --- a/stdlib/strlcat.c +++ b/stdlib/strlcat.c @@ -29,7 +29,7 @@ size_t strlcat(char *dest, const char *src, size_t size) size_t n; /* find the NULL terminator in dest */ - for (n = 0; i < size && dest[n] != '\0'; n++) + for (n = 0; n < size && dest[n] != '\0'; n++) ; /* destination was not NULL terminated. Return the initial size */ diff --git a/test/elfdebugprefix.asm b/test/elfdebugprefix.asm new file mode 100644 index 00000000..a67ba29c --- /dev/null +++ b/test/elfdebugprefix.asm @@ -0,0 +1,6 @@ +;Testname=unoptimized; Arguments=-O0 --debug-prefix-map elf=ELF -felf -oelfdebugprefix.o; Files=stdout stderr elfdebugprefix.o; Validate=readelf --wide --symbols elfdebugprefix.o | grep 'FILE.*ELFdebugprefix.asm' + + SECTION .text +test: ; [1] + ret + diff --git a/test/performtest.pl b/test/performtest.pl index f7865b39..096f9604 100755 --- a/test/performtest.pl +++ b/test/performtest.pl @@ -42,14 +42,22 @@ sub perform { TEST: while(<TESTFILE>) { #See if there is a test case - last unless /Testname=(.*);\s*Arguments=(.*);\s*Files=(.*)/; - my ($subname, $arguments, $files) = ($1, $2, $3); + last unless /Testname=(.*);\s*Arguments=(.*);\s*Files=([^;]*)(?:;\s*Validate=(.*))?/; + my ($subname, $arguments, $files, $validate) = ($1, $2, $3, $4); + chomp $files; debugprint("$subname | $arguments | $files"); #Call nasm with this test case system("$nasm $arguments $testpath > $stdoutfile 2> $stderrfile"); debugprint("$nasm $arguments $testpath > $stdoutfile 2> $stderrfile ----> $?"); + if($validate) { + if(system("$validate >> $stdoutfile 2>> $stderrfile") != 0) { + print "Test $testname/$subname validation failed\n"; + $globalresult = 1; + } + } + #Move the output to the test dir mkpath("$outputdir/$testname/$subname"); foreach(split / /,$files) { -- 2.23.0 |
From: Joshua W. <jpe...@gm...> - 2019-12-18 17:46:39
|
Adds a command line option --debug-prefix-map that changes the way file paths are encoded in debug information (similar to -fdebug-prefix-map in GCC). This allows nasm to generate reproducible output regardless of the location of the files. Joshua Watt (2): stdlib: Add strlcat Add --debug-prefix-map option Makefile.in | 2 +- asm/nasm.c | 26 ++++++++++++++++++++++++- configure.ac | 2 ++ include/compiler.h | 4 ++++ include/nasmlib.h | 9 +++++++++ nasm.txt | 4 ++++ nasmlib/filename.c | 20 +++++++++++++++++++ output/outas86.c | 4 +++- output/outcoff.c | 4 ++-- output/outelf.c | 2 +- output/outieee.c | 2 +- output/outobj.c | 2 +- stdlib/strlcat.c | 43 +++++++++++++++++++++++++++++++++++++++++ test/elfdebugprefix.asm | 6 ++++++ test/performtest.pl | 12 ++++++++++-- 15 files changed, 132 insertions(+), 10 deletions(-) create mode 100644 stdlib/strlcat.c create mode 100644 test/elfdebugprefix.asm -- 2.23.0 |
From: Cyrill G. <gor...@gm...> - 2019-06-03 07:47:50
|
On Sun, Jun 02, 2019 at 03:47:26PM -0700, hp...@zy... wrote: > > > >As to me -- we might need to walk over all instructions and add size > >specifiers where they are missing, but this require a lot of time. > >Maybe Peter has some idea? > > We really have to. Users expect it. I'll try to once time permit, but no promises :/ |
From: Cyrill G. <gor...@gm...> - 2019-06-02 20:21:53
|
On Tue, May 28, 2019 at 08:27:21PM +0000, Bae, Chang Seok wrote: > Hi all, > > [1] looks to have been open in quite a long period time; the size specifier has been broken obviously. > And I can see some benefits, [2] for instance. But fixing for those a few hundreds instances has been incremental (so far). > > At this point, I just wonder what’s our plan, at least for this open bug. Is it open to (radically) drop > the size specifier support?, or we need to keep fixing for those. > > [1] "error: mismatch in operand sizes" on scalar sse instruction, https://bugzilla.nasm.us/show_bug.cgi?id=978756 > [2] 3.7 STRICT: Inhibiting Optimization, https://www.nasm.us/xdoc/2.14.02/html/nasmdoc3.html#section-3.7 As to me -- we might need to walk over all instructions and add size specifiers where they are missing, but this require a lot of time. Maybe Peter has some idea? Cyrill |
From: Bae, C. S. <cha...@in...> - 2019-05-28 20:27:31
|
Hi all, [1] looks to have been open in quite a long period time; the size specifier has been broken obviously. And I can see some benefits, [2] for instance. But fixing for those a few hundreds instances has been incremental (so far). At this point, I just wonder what’s our plan, at least for this open bug. Is it open to (radically) drop the size specifier support?, or we need to keep fixing for those. Thanks, Chang [1] "error: mismatch in operand sizes" on scalar sse instruction, https://bugzilla.nasm.us/show_bug.cgi?id=978756 [2] 3.7 STRICT: Inhibiting Optimization, https://www.nasm.us/xdoc/2.14.02/html/nasmdoc3.html#section-3.7 |
From: Cyrill G. <gor...@gm...> - 2019-03-31 16:44:43
|
Hi Peter, I've just pushed out latex branch into main nasm repo. I think the commit message should explain everything I've done and what we've left to do. Take a look once time permit. Cyrill |
From: Cyrill G. <gor...@gm...> - 2019-01-14 20:08:52
|
On Mon, Jan 14, 2019 at 11:46:05AM -0800, H. Peter Anvin wrote: > Hi, > > I recently started looking at supporting > 64K sections in the ELF > backend. This is useful because subsections can be used in ELF for a > large number of things. The way > 64K sections is handled in ELF is that > the symbol table is augmented with an auxiliary section which contains > the extended section indicies. > > In the process, though, I just ran into a number of things that just > plain hurts; for one thing, we still do linear searches *everywhere* for > the segment:section matching, we have all these special sections which > we have ad hoc code to generate instead of using common code with the > ordinary sections to generate them, and there are a bunch of stuff where > we test is_elf*() for things that we could simply parameterize. > > This is not a criticism of Cyrill's ELF merge work; in fact, without > that work it would be utterly impossible to tackle this stuff at all. > > There is an alternative for the ELF backend, which would be to compile > it three times from a single source base. That way we would still have a > single codebase, but would be able to get the speed benefits of not > having a bunch of conditionals/parameters/etc. done at runtime, and > perhaps the best part of it would be that we can hide away the ELF32 v. > ELF64 differences. I personally rather like that solution, because I > think it would allow the code to be even cleaner as it would naturally > deal with most of the structure differences. > > I did prototype a version using an RAA for index->section and a hash for > name->section, as we currently do in the MachO backend. The speedup is > substantial: about a factor of 3 for 30K sections and then increasing > with the number of sections squared. This is stuff I can clean up and > productize easily enough; I need to detangle it from the other changes I > have been doing, though (or Chang, if you are interesting in tackling > that that would always be appreciated. > > However, all these changes make me nervous to push them into 2.14.xx. As > such, I would like to plan to make a 2.15 release before too much > longer, probably in Q2 2019. With Cyrill's testability changes, this has > a lot of other benefits. > > I *really* would like to see 2.15 including having at least the ELF and > MachO backends, and ideally COFF, changed to use the modern backend > interface. The current interface simply doesn't allow certain code > sequences from being handled correctly, and it makes me *very* nervous > that that is probabilistic. Sounds like a great plan! Peter, hopefully I manage to find timeslot on the week/weekend to fetch the new code and review it! I fear this week gonna be heavy but still. |
From: C. M. <pu...@38...> - 2019-01-13 11:38:10
|
Hello, I reviewed the revision at https://repo.or.cz/nasm.git/commitdiff/1df7263ae937ac11abb2c6938b8891745af91ce6 This change seems to be wrong: @@ -1575,10 +1570,6 @@ static void assemble_file(const char *fname, struct strlist *depend_list) preproc->cleanup_pass(); - /* Don't output further messages if we are dead anyway */ - if (terminate_after_phase) - break; - if (global_offset_changed) { switch (pass_type()) { case PASS_OPT: And in the following: +/* Pop the warning status off the warning stack */ +void pop_warnings(void) +{ + struct warning_stack *ws = warning_stack; + + memcpy(warning_state, ws->state, sizeof warning_state); + if (!ws->next) { + /*! + *!warn-stack-empty [on] warning stack empty + *! a [WARNING POP] directive was executed when + *! the warning stack is empty. This is treated + *! as a [WARNING *all] directive. + */ + nasm_warn(WARN_WARN_STACK_EMPTY, "warning stack empty"); + } else { + warning_stack = ws->next; + nasm_free(ws); + } ... It seems that WARN_WARN_STACK_EMPTY is issued depending on the *new* state of warning_state, meaning that warn-stack-empty can only be disabled or enabled from the command line. I think that it'd be more useful to issue the warning before applying the original warning_state content, so that the warning warn-stack-empty could be disabled by the input file without using the command line. Regards, ecm |
From: Ruslan K. <b7....@gm...> - 2018-12-16 11:42:50
|
On Sat, 15 Dec 2018 at 23:07, C. Masloch <pu...@38...> wrote: > > On at 2018-12-14 01:38 -0800, H. Peter Anvin wrote: > > On 12/4/18 4:02 AM, C. Masloch wrote: > >> > >> Oh yeah, you're right. Yes, it'd definitely be useful to support both > >> the operator and question mark in identifiers. > >> > > > > OK, the most logical way to deal with this seems to be to treat ? as a > > *keyword*, rather than a *character*. In other words, since ? is > > legitimate in identifiers, it is also a legitimate keyword. Just like > > any other keyword, it has to be separated from other keywords by > > whitespace or other non-identifier characters. > > Thanks, I tested building from git 33b5d21fbdc9 and it seems to handle everything the way it should, ie still allowing me to use the question mark in define names. > > >> (Side question: Would it be possible to "evaluate" expressions with > >> strings as result? Eg << db _FAT16 ? "FAT16" : "FAT12" >>. Currently I > >> use << db "FAT1",'2'+4*!!_FAT16 >> > >> https://bitbucket.org/ecm/ldosboot/src/b469e243526d4fbdfe79d6ef4ef677ff2372eb19/boot.asm#lines-490 > >> , which only uses a string that fits as a numeric constant in a byte.) > > > > I'm afraid not, although > > > > db "FAT1", _FAT16 ? '6' : '2' > > > > ... does work. > > > > This is because in NASM, strings used in expressions are always > > converted to numbers. This isn't something we can realistically change > > without who knows what breakage. > > Yeah, figures. > > > Now, since NASM does internal 64-bit arithmetic strings converted to > > numbers can be up to 8 characters long, but since there is no 5-byte > > object you can't trivially use it in the way you'd expect. > > > > Now, if you had an 8-byte field you could indeed do: > > > > dq _FAT16 ? "FAT16" : "FAT12" > > > > ... and you'd get a 5-character string with 3 bytes of zero padding. > > > A side question: Your mails never seem to show up in https://sourceforge.net/p/nasm/mailman/nasm-devel/ -- what's up with that? FWIW, it seems Peter's mails are not delivered to the mailing list at all. At least to me, from my inbox POV, this whole thread looks like a thread of a single author. Only quotations reveal Peter. > > Regards, > ecm > > > > _______________________________________________ > Nasm-devel mailing list > Nas...@li... > https://lists.sourceforge.net/lists/listinfo/nasm-devel |
From: C. M. <pu...@38...> - 2018-12-15 20:18:45
|
Hello, I want to provide a patch to add a warning label-missing-colon, which should trigger for every occurrence of a label without a colon (except when the label is defined using equ). That got me thinking, how should this be handled when interacting with orphan-labels? If orphan-labels is off, then I would apply label-missing-colon to every label, whether error-and-on, no-error-and-on, or off. Likewise, if label-missing-colon is off, applying orphan-labels is straightforward. (However, even that may require asking whether the one or the other is an enabled warning.) However, when both are on, the question is how to handle that? * Show both warnings? * Show only orphan-labels, since it's more specific? What if both are on and their error statuses differ? Especially the case of +error=label-missing-colon and -error=orphan-labels comes to mind. If we only show the more specific one and do *not* treat it as an error, then the demand to error for the more general one is not honoured. What do you think? Would such a patch be welcome? How should I handle this? Regards, ecm |
From: C. M. <pu...@38...> - 2018-12-15 20:06:55
|
On at 2018-12-14 01:38 -0800, H. Peter Anvin wrote: > On 12/4/18 4:02 AM, C. Masloch wrote: >> >> Oh yeah, you're right. Yes, it'd definitely be useful to support both >> the operator and question mark in identifiers. >> > > OK, the most logical way to deal with this seems to be to treat ? as a > *keyword*, rather than a *character*. In other words, since ? is > legitimate in identifiers, it is also a legitimate keyword. Just like > any other keyword, it has to be separated from other keywords by > whitespace or other non-identifier characters. Thanks, I tested building from git 33b5d21fbdc9 and it seems to handle everything the way it should, ie still allowing me to use the question mark in define names. >> (Side question: Would it be possible to "evaluate" expressions with >> strings as result? Eg << db _FAT16 ? "FAT16" : "FAT12" >>. Currently I >> use << db "FAT1",'2'+4*!!_FAT16 >> >> https://bitbucket.org/ecm/ldosboot/src/b469e243526d4fbdfe79d6ef4ef677ff2372eb19/boot.asm#lines-490 >> , which only uses a string that fits as a numeric constant in a byte.) > > I'm afraid not, although > > db "FAT1", _FAT16 ? '6' : '2' > > ... does work. > > This is because in NASM, strings used in expressions are always > converted to numbers. This isn't something we can realistically change > without who knows what breakage. Yeah, figures. > Now, since NASM does internal 64-bit arithmetic strings converted to > numbers can be up to 8 characters long, but since there is no 5-byte > object you can't trivially use it in the way you'd expect. > > Now, if you had an 8-byte field you could indeed do: > > dq _FAT16 ? "FAT16" : "FAT12" > > ... and you'd get a 5-character string with 3 bytes of zero padding. A side question: Your mails never seem to show up in https://sourceforge.net/p/nasm/mailman/nasm-devel/ -- what's up with that? Regards, ecm |
From: C. M. <pu...@38...> - 2018-12-11 14:25:13
|
Hello, I found a few spelling mistakes and missing blanks in some messages. I assume this patch should be trivial to apply. Regards, ecm >From c69e671a33183c23455ec117f576609fd953637a Mon Sep 17 00:00:00 2001 From: "C. Masloch" <pu...@38...> Date: Tue, 11 Dec 2018 15:21:18 +0100 Subject: [PATCH] fix some spelling mistakes Signed-off-by: C. Masloch <pu...@38...> --- asm/error.c | 4 ++-- output/outelf.c | 2 +- output/outmacho.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/asm/error.c b/asm/error.c index 73db7443..052bd630 100644 --- a/asm/error.c +++ b/asm/error.c @@ -47,7 +47,7 @@ * the [warning] directive. */ const struct warning warnings[ERR_WARN_ALL+1] = { - {"other", "any warning not specifially mentioned below", true}, + {"other", "any warning not specifically mentioned below", true}, {"macro-params", "macro calls with wrong parameter count", true}, {"macro-selfref", "cyclic macro references", false}, {"macro-defaults", "macros with more default than optional parameters", true}, @@ -68,7 +68,7 @@ const struct warning warnings[ERR_WARN_ALL+1] = { {"unknown-pragma", "unknown %pragma facility or directive", false}, {"not-my-pragma", "%pragma not applicable to this compilation", false}, {"unknown-warning", "unknown warning in -W/-w or warning directive", false}, - {"negative-rep", "regative %rep count", true}, + {"negative-rep", "negative %rep count", true}, {"phase", "phase error during stabilization", false}, /* THIS ENTRY MUST COME LAST */ diff --git a/output/outelf.c b/output/outelf.c index a32e1335..f9cebd7a 100644 --- a/output/outelf.c +++ b/output/outelf.c @@ -439,7 +439,7 @@ static int32_t elf_section_names(char *name, int pass, int *bits) if (!strcmp(name, ".shstrtab") || !strcmp(name, ".symtab") || !strcmp(name, ".strtab")) { - nasm_error(ERR_NONFATAL, "attempt to redefine reserved section" + nasm_error(ERR_NONFATAL, "attempt to redefine reserved section " "name `%s'", name); return NO_SEG; } diff --git a/output/outmacho.c b/output/outmacho.c index e78623e3..d53c5aaa 100644 --- a/output/outmacho.c +++ b/output/outmacho.c @@ -547,7 +547,7 @@ static int64_t add_reloc(struct section *sect, int32_t section, break; case RL_SUB: /* obsolete */ - nasm_error(ERR_WARNING, "relcation with subtraction" + nasm_error(ERR_WARNING, "relocation with subtraction " "becomes to be obsolete"); r->ext = 0; r->type = X86_64_RELOC_SUBTRACTOR; @@ -666,7 +666,7 @@ static void macho_output(int32_t secto, const void *data, nasm_error(ERR_WARNING, "attempt to initialize memory in " "BSS section: ignored"); /* FIXME */ - nasm_error(ERR_WARNING, "section size may be negative" + nasm_error(ERR_WARNING, "section size may be negative " "with address symbols"); s->size += realsize(type, size); return; -- 2.19.2 |
From: C. M. <pu...@38...> - 2018-12-04 12:02:45
|
On at 2018-12-03 16:29 -0800, H. Peter Anvin wrote: > Hi, > > Thank you for reporting so quickly. It pays off to browse the repo occasionally =) > This I guess negated my assumption that ? was only used in TASM mode. Yeah, and it was documented in the manual as well, at https://www.nasm.us/xdoc/2.14/html/nasmdoc3.html#section-3.1 : > Valid characters in labels are letters, numbers, _, $, #, @, ~, ., > and ?. The only characters which may be used as the first character > of an identifier are letters, . (with special meaning: see section > 3.9), _ and ?. > The ternary operator is *extremely* useful, in particular because of its > error-suppressing properties (which means that a lot of workarounds like > ((!!foo)*(bar))+(!foo)*(baz)) don't work the same. Oh yeah, you're right. Yes, it'd definitely be useful to support both the operator and question mark in identifiers. (Side question: Would it be possible to "evaluate" expressions with strings as result? Eg << db _FAT16 ? "FAT16" : "FAT12" >>. Currently I use << db "FAT1",'2'+4*!!_FAT16 >> https://bitbucket.org/ecm/ldosboot/src/b469e243526d4fbdfe79d6ef4ef677ff2372eb19/boot.asm#lines-490 , which only uses a string that fits as a numeric constant in a byte.) > I think we can make this work at the cost of complicating the lexical analysis > or require parentheses in certain ambiguous cases. The current NASM lexical > analyzer doesn't backtrack, and works one token at a time. However, there are > cases like: > > foo?bar?baz:quux > > ... where only at the end of the expression can you determine that either > foo?bar or bar?baz has to be an identifier, but not which one. And that still > requires a lexical analysis of the entire expression before it is possible to > make even that determination. > > Interestingly, disallowing '?' itself as an identifier makes it possible to > implement the MASM-like "db ?" syntax as equivalent to resb, and the "dup" > syntax really isn't that hard to do either. > > "%define ? 0" could still be made to work, since %define is followed by a > token, not an expression. It would, of course, replace *ALL* ? (except in > strings) with 0 (which would be a hack around your particular situation, but > wouldn't work for anyone who cares about the symbols in the output format. I don't think this actually works for my use case. If it would replace *all* question marks with zero, one of my labels like "?frame_bp" would look like "0frame_bp" to NASM, which is not a valid identifier. But I'm not sure you mean that? Regards, ecm |
From: C. M. <pu...@38...> - 2018-12-03 20:27:11
|
Hi, In the commit https://repo.or.cz/nasm.git/commitdiff/a0743398543202cc4fee33921820e33a2b5a4c3d you changed isidstart to not allow the question mark '?' in identifiers any longer. I understand that this is related to https://repo.or.cz/nasm.git/commitdiff/099cc177398df447ee7153ab29337f00dbcc9d16 which adds the ternary ? : operator. However, in my collection of macros (at https://bitbucket.org/ecm/lmacros -- look for lmacros2.mac's lframe, lvar, lpar, lenter, lleave) I'm using the question mark in identifiers for stack frame labels, primarily to distinguish the labels from any other kinds of labels. But also because I need to prefix or suffix the labels with something to avoid existing labels interfering with %define or %undef operation. (Ie, %undef %1 will first expand %1 to the first macro parameter, and if that is the name of an existing define, it will expand that define too. So %undef gets the contents of the define, not the define name. %undef ?%1 expands the %1 but doesn't expand the define.) A few observations: * When using ? in the ternary operator, there must be a valid expression term in front of it. And there must not be any unary or binary operators there (like - and +), because these imply that the ? is the start of an expression term itself (not the first part of the ternary operator). * In my use case, there is never whitespace after the ?. (However, it may be convenient when porting to "%define ? 0" for "db ?" cases.) * In my use case, there is never a colon in the expression tail after the question mark. Ideally, I'd like if you could either default to or add either a switch / several switches (or pragmas, or whatever) to either use a heuristic, or always treat question marks as parts of identifiers. (The latter case might disallow using the ternary operator, which if so tips this in favor of some heuristic.) Regards, ecm |
From: C. M. <pu...@38...> - 2018-11-27 20:10:10
|
On at 2018-11-27 19:29 +0300, Cyrill Gorcunov wrote: > On Tue, Nov 27, 2018 at 04:40:45PM +0100, C. Masloch wrote: >> Hi, the bugzilla bug entry page seems to be broken. My browser (Firefox >> 52.9.0 on Debian testing amd64) replies with this error message upon >> clicking "Submit Bug" on https://bugzilla.nasm.us/enter_bug.cgi >> >>> File not found >>> >>> Firefox can't find the file at https://bugzilla.nasm.us/post_bug.cgi. >>> >>> Check the file name for capitalisation or other typing errors. >>> Check to see if the file was moved, renamed or deleted. > > Weird, people been submitting bugs just a couple days ago. > Maybe it is some firefox issue? Could you please clear > the browser cache and retry? I retried now and the page loaded normally this time. It just complained that there was no "2.14 (development)" version any longer, which was fixed by reloading enter_bug.cgi, re-entering everything, and selecting the new "2.14.xx" version instead. Thanks anyway! Regards, ecm |
From: Ed B. <be...@mi...> - 2018-11-27 17:20:51
|
On 11/27/18 11:29 AM, Cyrill Gorcunov wrote: > On Tue, Nov 27, 2018 at 04:40:45PM +0100, C. Masloch wrote: >> Hi, the bugzilla bug entry page seems to be broken. My browser (Firefox >> 52.9.0 on Debian testing amd64) replies with this error message upon >> clicking "Submit Bug" on https://bugzilla.nasm.us/enter_bug.cgi >> >>> File not found >>> >>> Firefox can't find the file at https://bugzilla.nasm.us/post_bug.cgi. >>> >>> Check the file name for capitalisation or other typing errors. >>> Check to see if the file was moved, renamed or deleted. > > Weird, people been submitting bugs just a couple days ago. > Maybe it is some firefox issue? Could you please clear > the browser cache and retry? If it helps, I just browsed there using Firefox 63.0.3 (64-bit) under Linux and saw no errors. Ed |
From: Cyrill G. <gor...@gm...> - 2018-11-27 16:29:47
|
On Tue, Nov 27, 2018 at 04:40:45PM +0100, C. Masloch wrote: > Hi, the bugzilla bug entry page seems to be broken. My browser (Firefox > 52.9.0 on Debian testing amd64) replies with this error message upon > clicking "Submit Bug" on https://bugzilla.nasm.us/enter_bug.cgi > > > File not found > > > > Firefox can't find the file at https://bugzilla.nasm.us/post_bug.cgi. > > > > Check the file name for capitalisation or other typing errors. > > Check to see if the file was moved, renamed or deleted. Weird, people been submitting bugs just a couple days ago. Maybe it is some firefox issue? Could you please clear the browser cache and retry? |