C:/DJGPP-2.05/BIN/make.exe -C common[...]
gcc ... -c dbgcom.c
dbgcom.c: Assembler messages:
dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined
I have tried this using gcc1010 and gcc1020. Both fails. If I use gcc920 everything works fine. In all cases bnu234b has been used and no other one has been tried.
I have tried to compile the the repository code of libc and the compiler stoped with the follwing error message:
C:/DJGPP-2.05/BIN/make.exe -C common
gcc ... -c dbgcom.c
dbgcom.c: Assembler messages:
dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined make[3]: *** [../../makefile.inc:90: dbgcom.o] Error 1
make[2]: *** [makefile.sub:2: all_subs] Error 2
make[1]: *** [../makefile.lib:7: all] Error 2
make: *** [makefile:45: subs] Error 2
I have tried this using gcc1010 and gcc1020. Both fails. If I use gcc920 everything works fine. In all cases bnu234b has been used and no other one has been tried.
Am 10.12.2020 12:55, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
C:/DJGPP-2.05/BIN/make.exe -C common[...]
gcc ... -c dbgcom.c
dbgcom.c: Assembler messages:
dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already
defined
dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already
defined
I have tried this using gcc1010 and gcc1020. Both fails. If I use
gcc920
everything works fine. In all cases bnu234b has been used and no other
one
has been tried.
Some kind of gcc bug? How does the asm output of gcc look like?
I have attached both assembly files, one produced by 9.2.0 and the other
one
produced by 10.2.0. The offending code starts at 1337 where some asm code
is
inserted. For some reason the labels used repeats a couple of times in the assembler output.
I have tried to compile the the repository code of libc and the compiler stoped with the follwing error message:
C:/DJGPP-2.05/BIN/make.exe -C common
gcc ... -c dbgcom.c
dbgcom.c: Assembler messages:
dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined make[3]: *** [../../makefile.inc:90: dbgcom.o] Error 1
make[2]: *** [makefile.sub:2: all_subs] Error 2
make[1]: *** [../makefile.lib:7: all] Error 2
make: *** [makefile:45: subs] Error 2
I have tried this using gcc1010 and gcc1020. Both fails. If I use gcc920 everything works fine. In all cases bnu234b has been used and no other one has been tried.
Of course there are a lot of other warnings that aborts the compilation like: d:/djgpp/include/time.h: In function 'asctime':
ctime.c:1553:55: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", | ^~
ctime.c:1553:26: note: directive argument in the range [-2147481748, 2147483647]
1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctime.c:1553:10: note: 'sprintf' output between 17 and 68 bytes into a destination of size 26
1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1554 | wday_name[timeptr->tm_wday], | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1555 | mon_name[timeptr->tm_mon], | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 1556 | timeptr->tm_mday, timeptr->tm_hour,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1557 | timeptr->tm_min, timeptr->tm_sec, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1558 | TM_YEAR_BASE + timeptr->tm_year); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
d:/djgpp/include/time.h: In function 'ctime':
ctime.c:1553:55: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", | ^~
ctime.c:1553:26: note: directive argument in the range [-2147481748, 2147483647]
1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctime.c:1553:10: note: 'sprintf' output between 17 and 68 bytes into a destination of size 26
1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1554 | wday_name[timeptr->tm_wday], | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1555 | mon_name[timeptr->tm_mon], | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 1556 | timeptr->tm_mday, timeptr->tm_hour,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1557 | timeptr->tm_min, timeptr->tm_sec, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1558 | TM_YEAR_BASE + timeptr->tm_year); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or:
d:/djgpp/include/io.h: In function '_chmod':
_chmod.c:28:14: warning: array subscript 1 is outside array bounds of 'int[1]' [-Warray-bounds]
28 | r.x.cx = *(&func + 1); /* Value to set */
| ^~~~~~~~~~~~
_chmod.c:14:34: note: while referencing 'func'
14 | _chmod(const char *filename, int func, ...)
| ~~~~^~~~
The -Warray-bounds appears quite a lot due to our way to address neighborhood variables as can
be seen in the example above. May be some with some spare time can fix these occurencies.
Regards,
Juan M. Guerrero
Also note that linking will fail with gcc 10 since it now uses -fno-common
by default, I worked around that with the following patch:
On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
Also note that linking will fail with gcc 10 since it now uses -fno-common
-fno-common can be a good thing..
by default, I worked around that with the following patch:
Which are the duplicated symbols causing trouble?
dbgcom.c: Assembler messages:
dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined
Nevertheless, gcc-10 seems to have inlined invalid_sel_addr()
which has the asm, into read_sel_addr() hence the duplicated
labels.
I ran into this also with gcc 9, I guess it depends on the optimization flags you specify (I like to use -O3). I think local labels should start with 'L' only (no leading '.'), that is also how gcc generates label names.
If the asm is inlined into the same function twice, then you still have duplicate local labels and you need to add add %= to the label name which generates a unique ID for each asm instance.
Which are the duplicated symbols causing trouble?
Only __stdio_cleanup_hook in libc, which I marked extern, and almost all global
symbols in fsdb. I figured it would be okay to compile just fsdb with -fcommon.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Thu, 10 Dec 2020 20:44:01 +0300
--- src/debug/fsdb/makefile 27 Sep 1998 17:04:26 -0000 1.3
+++ src/debug/fsdb/makefile 10 Dec 2020 17:39:43 -0000
@@ -12,6 +12,9 @@ EOBJS += unassmbl.o
include $(TOP)/../makefile.inc
+#see screen.h as to why this is needed
+CFLAGS += -fcommon
+
--- src/libc/ansi/stdlib/exit.c 2 May 2015 07:32:10 -0000 1.9
+++ src/libc/ansi/stdlib/exit.c 10 Dec 2020 17:39:43 -0000
@@ -15,7 +15,7 @@
struct __atexit *__atexit_ptr = 0;
-void (*__stdio_cleanup_hook)(void);
+extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Thu, 10 Dec 2020 20:44:01 +0300
--- src/debug/fsdb/makefile 27 Sep 1998 17:04:26 -0000 1.3
+++ src/debug/fsdb/makefile 10 Dec 2020 17:39:43 -0000
@@ -12,6 +12,9 @@ EOBJS += unassmbl.o
include $(TOP)/../makefile.inc
+#see screen.h as to why this is needed
+CFLAGS += -fcommon
+
This part looks OK.
--- src/libc/ansi/stdlib/exit.c 2 May 2015 07:32:10 -0000 1.9
+++ src/libc/ansi/stdlib/exit.c 10 Dec 2020 17:39:43 -0000
@@ -15,7 +15,7 @@
struct __atexit *__atexit_ptr = 0;
-void (*__stdio_cleanup_hook)(void);
+extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */
This part I don't understand: are you saying that it is no longer the
default that a function not explicitly declared 'static' has the
external linkage? Why do we need an explicit 'extern' qualifier?
Thanks.
--- src/libc/ansi/stdlib/exit.c 2 May 2015 07:32:10 -0000 1.9
+++ src/libc/ansi/stdlib/exit.c 10 Dec 2020 17:39:43 -0000
@@ -15,7 +15,7 @@
struct __atexit *__atexit_ptr = 0;
-void (*__stdio_cleanup_hook)(void);
+extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */
This part I don't understand: are you saying that it is no longer the
default that a function not explicitly declared 'static' has the
external linkage? Why do we need an explicit 'extern' qualifier?
On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]<djgpp@delorie.com> wrote:
Which are the duplicated symbols causing trouble?
Only __stdio_cleanup_hook in libc, which I marked extern, and almost all global
symbols in fsdb. I figured it would be okay to compile just fsdb with -fcommon.
The attached patch avoid duplicated symbols with gcc-10
where -fno-common is on by default.
The patch is from J. W. Jagersma, I only added comments.
OK to apply?
--
O.S.
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Thu, 10 Dec 2020 19:55:11 +0100
-void (*__stdio_cleanup_hook)(void);
+extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */
This part I don't understand: are you saying that it is no longer the default that a function not explicitly declared 'static' has the
external linkage? Why do we need an explicit 'extern' qualifier?
Thanks.
This only applies to global variables (and __stdio_cleanup_hook here is a function *pointer*), functions themselves still have implicit external linkage.
I'm not a C language lawyer but this page suggests that it was always an error
to omit 'extern' on global variable declarations. It just wasn't reported as such, until now:
https://gcc.gnu.org/gcc-10/porting_to.html
This only applies to global variables (and __stdio_cleanup_hook here is a function *pointer*), functions themselves still have implicit external linkage.
I'm not a C language lawyer but this page suggests that it was always an error
to omit 'extern' on global variable declarations. It just wasn't reported as such, until now:
https://gcc.gnu.org/gcc-10/porting_to.html
Applied the patch to debug/fsdb/makefile, utils/djtar/makefile,
and libc/ansi/stdlib/exit.c
Can someone review the dbgcom.patch ?
Am 10.12.2020 21:10, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
Applied the patch to debug/fsdb/makefile, utils/djtar/makefile,
and libc/ansi/stdlib/exit.c
Can someone review the dbgcom.patch ?
Apply it. It works.
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Thu, 10 Dec 2020 19:55:11 +0100
-void (*__stdio_cleanup_hook)(void);
+extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */
This part I don't understand: are you saying that it is no longer the
default that a function not explicitly declared 'static' has the
external linkage? Why do we need an explicit 'extern' qualifier?
Thanks.
This only applies to global variables (and __stdio_cleanup_hook here is a
function *pointer*), functions themselves still have implicit external linkage.
And global variables don't?
d:/djgpp/include/io.h: In function '_chmod':
_chmod.c:28:14: warning: array subscript 1 is outside array bounds of 'int[1]' [-Warray-bounds]
28 | r.x.cx = *(&func + 1); /* Value to set */
| ^~~~~~~~~~~~
_chmod.c:14:34: note: while referencing 'func'
14 | _chmod(const char *filename, int func, ...)
| ~~~~^~~~
The -Warray-bounds appears quite a lot due to our way to address
neighborhood variables as can
be seen in the example above. May be some with some spare time can fix
these occurencies.
On 12/10/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]<djgpp@delorie.com> wrote:What is today a nasty shortcut was a cool one 30 years ago.
d:/djgpp/include/io.h: In function '_chmod':
_chmod.c:28:14: warning: array subscript 1 is outside array bounds of
'int[1]' [-Warray-bounds]
28 | r.x.cx = *(&func + 1); /* Value to set */
| ^~~~~~~~~~~~
_chmod.c:14:34: note: while referencing 'func'
14 | _chmod(const char *filename, int func, ...)
| ~~~~^~~~
The -Warray-bounds appears quite a lot due to our way to address
neighborhood variables as can
be seen in the example above. May be some with some spare time can fix
these occurencies.
As far as I can see, this particular case is intending this
using a nasty shortcut?
--- _chmod.c~Looks ok to me. Will do the job; alternatively we would have to disable that check.
+++ _chmod.c
@@ -9,7 +9,8 @@
#include<dpmi.h>
#include<fcntl.h>
#include<libc/dosio.h>
-
+#include<stdarg.h>
+
int
_chmod(const char *filename, int func, ...)
{
@@ -25,7 +26,12 @@ _chmod(const char *filename, int func, .
r.x.ax = 0x4300 + func;
_put_path(filename);
if (func == 1)
- r.x.cx = *(&func + 1); /* Value to set */
+ {
+ va_list ap;
+ va_start (ap, func);
+ r.x.cx = va_arg(ap, int); /* Value to set */
+ va_end (ap);
+ }
r.x.dx = __tb_offset;
r.x.ds = __tb_segment;
__dpmi_int(0x21,&r);
Correct? Any others like this?
As far as I can see, this particular case is intending thisWhat is today a nasty shortcut was a cool one 30 years ago.
using a nasty shortcut?
Correct? Any others like this?Looks ok to me. Will do the job; alternatively we would have to disable
that check.
On 12/11/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
As far as I can see, this particular case is intending thisWhat is today a nasty shortcut was a cool one 30 years ago.
using a nasty shortcut?
No arguments there.
Correct? Any others like this?Looks ok to me. Will do the job; alternatively we would have to disable
that check.
Attached a patch that applies to current CVS.
However, the asm outputs differ. Tried gcc-3.4.6 and gcc-8.2.0,
asm outputs from both are attached here (*_0.s for original and
*_1.s for patched.) Also attached diffs of *.s for convenience.
Someone good with x86 asm should verify.
On 12/11/20, Ozkan Sezer<sezeroz@gmail.com> wrote:
On 12/11/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]<djgpp@delorie.com> wrote:
As far as I can see, this particular case is intending thisWhat is today a nasty shortcut was a cool one 30 years ago.
using a nasty shortcut?
No arguments there.
Correct? Any others like this?Looks ok to me. Will do the job; alternatively we would have to disable >>> that check.
Attached a patch that applies to current CVS.
However, the asm outputs differ. Tried gcc-3.4.6 and gcc-8.2.0,
asm outputs from both are attached here (*_0.s for original and
*_1.s for patched.) Also attached diffs of *.s for convenience.
Someone good with x86 asm should verify.
Has anyone had a chance to look at this?
The v1.2 commit to machine/endian.h defined some macros which may be problematic, e.g. __BIG_ENDIAN__: notice the leading _and_ trailing double-underscores. http://www.delorie.com/bin/cvsweb.cgi/djgpp/include/machine/endian.h
Gcc from big-endian targeting toolchains have a tendency for defining __BIG_ENDIAN__, e.g.:
$ /opt/cross_osx-ppc/bin/powerpc-apple-darwin9-gcc -E -dD -xc /dev/null | \
grep ENDIAN
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
$ /gg/bin/ppc-morphos-gcc -E -dD -xc /dev/null | grep ENDIAN
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
$ /opt/cross_amigaos4/bin/ppc-amigaos-gcc -E -dD -xc /dev/null | \
grep ENDIAN
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
I suggest removing the additional macros with both leading and trailing double-underscores, i.e. like the following patch:
Index: include/machine/endian.h ===================================================================
RCS file: /cvs/djgpp/djgpp/include/machine/endian.h,v
retrieving revision 1.2
diff -u -r1.2 endian.h
--- include/machine/endian.h 6 Jan 2021 14:55:05 -0000 1.2
+++ include/machine/endian.h 13 Jan 2021 16:23:19 -0000
@@ -54,11 +54,6 @@
#define __PDP_ENDIAN PDP_ENDIAN
#define __BYTE_ORDER LITTLE_ENDIAN
-#define __LITTLE_ENDIAN__ LITTLE_ENDIAN
-#define __BIG_ENDIAN__ BIG_ENDIAN
-#define __PDP_ENDIAN__ PDP_ENDIAN
-#define __BYTE_ORDER__ LITTLE_ENDIAN
-
#include <sys/cdefs.h>
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 431 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:56:23 |
| Calls: | 9,075 |
| Calls today: | 5 |
| Files: | 13,405 |
| Messages: | 6,019,512 |