gcl-devel
[Top][All Lists]
Advanced

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

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


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: GCL on OpenBSD: estack_buf missing
Date: 11 Feb 2004 19:03:59 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Magnus Henoch <address@hidden> writes:

> 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.
> 

OK, once we get this settled, then we can set you up as a developer on
the savannah website.  You will need to register there as a user.
Thanks for your interest!

> > 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.
> 

Indeed, you are correct.  I was confused with isfinite.

> [...]
> 
> > 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?
> 

Not extensively at present, alas, but what there is can be had with

./configure --help

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

OK.  This should pull in the sfaslelf.c relocation file.

> [...]
> 
> >> 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
>  

OK, at the very least we will commit this, thanks!  But better still
would be to comment this setting out, as in linux.defs, as configure
should set the LIBS variable up completely.  Could you please test
this? 


> 
> 
> >> 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.

Agreed.  I suggest we have configure establish an ELF_HEADER macro,
leave HAVE_ELF alone, and define ELFW/ElfW in the platform-specific
headers, like solaris.h.  Eventaully, everything should go in
configure, but in the short run, static edits to the .h/.defs file are
much preferable to editing the core files.

> 
> 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.
> 

OK.  I'd also suggest including linux.h in your .h file and redefining
stuff as necessary.  The bulk should be correct, and its best not to
duplicate code.

> 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
> 

OK, if you are sure of the mapping this should be OK, but you might be
better off in this instance trying a bfd relocation build.  I think
this is what Mark had going.

> 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.
> 

OK, please report this backtrace when recompiled with --enable-debug. Thanks!

> [...]
> 
> > You may have difficulties with propolice -- I'd suggest turning it off
> > initially. 
> 
> And I forgot that too...
> 

Likely the cause of the above.

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

Great!  Most of the bsd cleanup stuff should go into CVS HEAD at this
point, as we're quite close now to releasing 2.6.2 as the next stable
tree.  Is this OK for you?

Take care,

> Magnus
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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