gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: GCL on OpenBSD: estack_buf missing


From: Magnus Henoch
Subject: [Gcl-devel] Re: GCL on OpenBSD: estack_buf missing
Date: Mon, 09 Feb 2004 23:25:41 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Camm Maguire <address@hidden> writes:

> Greetings, and thanks for your report!  We now have known users for
> each of the three BSD varieties!  Unfortunately there is somewhat of
> a challenge at present keeping all three in sync.  I will endeavor in
> the next few days to go through Mark Murray's remaining patch
> submissions, in which he greatly simplifies things by centralizing
> shared unix config settings in the linux.h file.  At that point, I'd
> greatly appreciate a volunteer from each BSD to sign on as a GCL
> developer, and take responsibility for maintaining the appropriate .h
> and .defs files.  From there, I'd like to begin shrinking and
> eventually eliminating these files via an expanded configure script. 
>
> Perhaps you or someone you know would like to volunteer?

Yes, I will try.  I realize that I don't understand much of what the
code is really doing, but I hope I will learn along the way.

> In any case, at present our best supported bsd is freebsd, so I'd
> suggest you try ./configure --enable-machine=freebsd and report
> differences from there.

I have made some progress starting from the FreeBSD settings.

[...]

> Zero is not normal?

At least the FreeBSD manpage cleary says that isnormal should return
false for zero.

[...]

> This is correct, and I'll apply, thanks!  But your build should not be
> getting here if you are using, as recommended, either the
> --enable-statsysbfd relocation option to configure, or the
> --disable-statsysbfd --enable-custreloc options (or even
> --disable-statsysbfd --enable-locbfd if you can't have your own bfd
> library).

Where are these recommendations documented?

Anyway, all of the following is with --disable-statsysbfd
--enable-custreloc.

[...]

>> Index: unixport/makefile
>> ===================================================================
>> RCS file: /cvsroot/gcl/gcl/unixport/makefile,v
>> retrieving revision 1.51
>> diff -u -r1.51 makefile
>> --- unixport/makefile        2 Dec 2003 20:16:56 -0000       1.51
>> +++ unixport/makefile        1 Feb 2004 14:20:37 -0000
>> @@ -14,7 +14,7 @@
>>  PORTDIR = $(shell pwd)
>>  
>>  LD_LIBS_PRE=$(addprefix -u ,$(PATCHED_SYMBOLS))
>> -LD_LIBS_POST=$(LIBS) $(LIBC) -lgclp
>> +LD_LIBS_POST=$(LIBS) $(LIBC) -lgclp -lbfd -liberty -lreadline -lncurses
>>  
>
> Same issue as above.
>

FreeBSD.defs resets LIBS.  The following fixes it:

Index: h/FreeBSD.defs
===================================================================
RCS file: /cvsroot/gcl/gcl/h/FreeBSD.defs,v
retrieving revision 1.2
diff -u -r1.2 FreeBSD.defs
--- h/FreeBSD.defs      1 Nov 2002 04:09:34 -0000       1.2
+++ h/FreeBSD.defs      8 Feb 2004 20:55:12 -0000
@@ -6,7 +6,7 @@
 
 OFLAG  = -pipe -O2 
 CFLAGS = -fwritable-strings -fomit-frame-pointer -DVOL=volatile -I$(GCLDIR)/o 
-I/usr/local/lib/gcl-2.0/h -fsigned-char -I/usr/local/lib
-LIBS    = -lm -L/usr/local/lib
+LIBS   += -lm -L/usr/local/lib
 ODIR_DEBUG=
 NULLFILE=../h/twelve_null
 


>> sed: 1: "s,@LI-MINVERS@,7.0,1": bad flag in substitute command: 'u'
>
> All my experience is with gnu sed, and I've never seen this.  Is
> something truncating the command after a certain number of chars?

Something like that.  I reported it as a bug (number 3677), and
shortly someone came up with a patch.

I found that OpenBSD for some reason has elf_abi.h instead of elf.h.
Thus the following:

Index: configure.in
===================================================================
RCS file: /cvsroot/gcl/gcl/configure.in,v
retrieving revision 1.139
diff -u -r1.139 configure.in
--- configure.in        16 Jan 2004 16:56:54 -0000      1.139
+++ configure.in        8 Feb 2004 20:55:12 -0000
@@ -900,6 +900,9 @@
 
 AC_CHECK_HEADERS(sys/ioctl.h)
 
+# OpenBSD has elf_abi.h instead of elf.h
+AC_CHECK_HEADERS(elf.h elf_abi.h)
+
 
 #--------------------------------------------------------------------
 #      The code below deals with several issues related to gettimeofday:

and combined with some macros defined differently, this:

Index: unixport/rsym_elf.c
===================================================================
RCS file: /cvsroot/gcl/gcl/unixport/rsym_elf.c,v
retrieving revision 1.12
diff -u -r1.12 rsym_elf.c
--- unixport/rsym_elf.c 3 Dec 2003 16:01:59 -0000       1.12
+++ unixport/rsym_elf.c 8 Feb 2004 20:55:15 -0000
@@ -27,7 +27,28 @@
 #include "ext_sym.h"
 
 
+#if defined(HAVE_ELF_H)
 #include <elf.h>
+#elif defined(HAVE_ELF_ABI_H)
+#include <elf_abi.h>
+#else
+#error Neither elf.h nor elf_abi.h found
+#endif
+
+/* For OpenBSD */
+#ifndef ElfW
+/* ElfW(type) becomes Elf32_type or Elf64_type, respectively.
+ * Defined in link.h on Linux.  OpenBSD does this in another way:
+ * by defining Elf_Ehdr etc to the correct type in exec_elf.h.
+ */
+#ifdef Elf_Ehdr
+#define ElfW(type) Elf_##type
+#else
+#error Neither ElfW nor Elf_Ehdr defined
+#endif
+
+#endif
+
 ElfW(Phdr) pheader;
 ElfW(Ehdr) eheader;
 ElfW(Sym) *symbol_table;
@@ -36,7 +57,13 @@
 #undef EXT_and_TEXT_BSS_DAT
 /* #define mjoin(a,b) a ## b */
 /* #define Mjoin(a,b) mjoin(a,b) */
+#if defined(__ELF_NATIVE_CLASS)
 #define ELFW(a) Mjoin(ELF,Mjoin(__ELF_NATIVE_CLASS,Mjoin(_,a)))
+#elif defined(ELFSIZE)
+#define ELFW(a) Mjoin(ELF,Mjoin(ELFSIZE,Mjoin(_,a)))
+#else
+#error Neither __ELF_NATIVE_CLASS nor ELFSIZE defined
+#endif
 
 int nsyms;
 char *my_string_table;

The definitions of ElfW and ELFW above really should be in some header
file, but they require elf{,_abi}.h to be included first.  I'm not
sure of the best way to do that.

Just for building this, I #included gclincl.h and elf{,_abi}.h in
FreeBSD.h, added the definition of ElfW, and copied SEEK_TO_END_OFILE
from linux.h.  This will definitely need to be cleaner.

For o/sfaslelf.c, I found that all the relocation constants (R_386_*)
are defined in <i386/reloc.h> and called RELOC_* instead.  I just did
a global search-and-replace to see where all this would lead;  maybe
this could be done with

#ifdef RELOC_NONE
        case RELOC_NONE:
#else
        case R_386_NONE:
#endif

for all of the cases in the switch statement around line 540.

Finally, the build process progressed unto building raw_pre_gcl.  When
trying to use it, it segfaults and the error causes an infinite
recursive loop:

cp init_pre_gcl.lsp foo
echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")" >>foo
/home/magnus/noarchive/src/gcl/unixport/raw_pre_gcl 
/home/magnus/noarchive/src/gcl/unixport/ -libdir 
/home/magnus/noarchive/src/gcl/ < foo
Memory fault (core dumped) 
gmake[1]: *** [saved_pre_gcl] Error 139
rm init_pre_gcl.lsp
gmake[1]: Leaving directory `/home/magnus/noarchive/src/gcl/unixport'
gmake: *** [unixport/saved_pre_gcl] Error 2


GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.4"...
Core was generated by `raw_pre_gcl'.
Program terminated with signal 11, Segmentation fault.
#0  0x19e31fd in ?? ()
(gdb) bt
#0  0x19e31fd in ?? ()
#1  0x19de4ec in ?? ()
#2  0x1c0029ab in error ()
#3  0x1a089f1 in ?? ()
#4  0x19f7097 in ?? ()
#5  0x19e3257 in ?? ()
#6  0x19de4ec in ?? ()
#7  0x1c0029ab in error ()
#8  0x1a089f1 in ?? ()
#9  0x19f7097 in ?? ()
#10 0x19e3257 in ?? ()
#11 0x19de4ec in ?? ()
#12 0x1c0029ab in error ()
...
#18345 0x19e3257 in ?? ()
#18346 0x19de4ec in ?? ()
#18347 0x1c0029ab in error ()
#18348 0x61c29a1 in ?? ()
#18349 0x61c2166 in ?? ()
#18350 0xcfbf44cc in ?? ()

Hmm, seems I forgot debugging symbols.  I'll try that later.

[...]

> You may have difficulties with propolice -- I'd suggest turning it off
> initially. 

And I forgot that too...

Thus, I'm making progress and expect more of it to come.

Magnus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]