Date: Mon, 18 Aug 2008 09:37:12 +0100 From: Anton Shterenlikht <mexas@bristol.ac.uk> To: ticso@cicely.de Cc: freebsd-alpha@freebsd.org Subject: Re: firefox3 build fails on alpha Message-ID: <20080818083712.GA1032@mech-cluster238.men.bris.ac.uk> In-Reply-To: <20080816161820.GG37139@cicely7.cicely.de> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <op.ud7arxvc9aq2h7@mezz.mezzweb.com> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <g723t3$jcd$1@lorvorc.mips.inka.de> <20080816161820.GG37139@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 16, 2008 at 06:18:20PM +0200, Bernd Walter wrote: > On Sat, Aug 02, 2008 at 05:01:23PM +0000, Christian Weisgerber wrote: > > Anton Shterenlikht <mexas@bristol.ac.uk> wrote: > > > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > In this particular case it seems that (at least) 2 files > > > are missing from the distribution: > > > > > > xptcinvoke_freebsd_alpha.cpp > > > xptcstubs_freebsd_alpha.cpp > > > > Yes. These need to be created. > > > > You have stumbled on a dirty secret: the Mozilla family programs > > rely on a part that must be ported at the assembly(!) language level > > to each processor/compiler/(operating system) combination. > > > > > I think that whoever created the tar file simply forgot to add the freebsd > > > files. > > > > No, somebody needs to write them. > > I wrote them a few years back for mozilla and they were part of the port. > Don't know what happened in the meantime, because since alpha support is > removed I stopped spending time into it. > The whole xptcinvoke thing is completely breandead anyway. > The intention was to have a portable interfacing to modules, but in fact > they just read the C++ vtable using assembly, which the compiler can do > without any help. > The assembly calling functions need to know the compiler specific > vtable and not a fixed self defined, which is not what I expected to see. > It took me several days to understand that they want something senseless. Anyway, I seem to have fixed this. The build now passes this stage but fails at another. The mozilla developers 'don't know' how to fix it, and apparently lost the interest. Anybody here cares to comment? Something to do with incorrect alignment. Please see below the bugzilla thread. https://bugzilla.mozilla.org/show_bug.cgi?id=449373 "I'm building firefox3.0.1 on FreeBSD-6.3-stable Alpha. I get this error message: gmake[5]: Entering directory `/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src' nsCookieService.cpp c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/storage -I../../../dist/include -I../../../dist/include/necko -I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h nsCookieService.cpp ../../../dist/include/xpcom/nsTHashtable.h: In static member function `static PRBool nsTHashtable<EntryType>::s_MatchEntry(PLDHashTable*, const PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]': ../../../dist/include/xpcom/nsTHashtable.h:335: instantiated from `PRBool nsTHashtable<EntryType>::Init(PRUint32) [with EntryType = nsCookieEntry]' nsCookieService.cpp:418: instantiated from here ../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type gmake[5]: *** [nsCookieService.o] Error 1 Reproducible: Always Steps to Reproduce: 1. get FreeBSD-6.3-Alpha 2. cd /usr/ports/www/firefox3 3. make Actual Results: ../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type I believe this warning indicates a problem that leads to failure of compilation of nsCookieService.cpp Comment #1 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-06 07:57:51 PDT This is an interesting bug, and it may be "real" in some sense. nsTHashtable is a wrapper around the pldhash code, which places entries (which begin with or are derived from PLDHashEntryHdr) in a contiguous array. It uses sizeof(entry) as the entry size, which may not be the same as the required alignment for the entry type. What is the required alignment of nsCookieEntry and PLDHashEntryHdr? Is there a way for the compiler to tell us what the required alignment is? If so, we may need to extend the entry size to the required alignment. In that case we "know" that the PLDHashEntryHdr* is of the required alignment, and this cast should be safe... then how do we tell the compiler that it's a safe cast? In an private mail from Anton he says that this worked in FF2 but broke in FF3 because previously we were using NS_REINTERPRET_CAST and we're now using reinterpret_cast<>(), but these should have been equivalent on any modern C++ compiler. Also, it seems like this could be a static_cast instead of a reinterpret_cast, since in nsTHashtable the entry types are always derivatives. I can provide a patch to that effect to see if it helps. Comment #2 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-06 09:09:44 PDT Created an attachment (id=332545) [details] nsTHashtable use static_cast and not reinterpret_cast, rev. 1 Anton, please try this patch and let me know whether it helps. Comment #4 [reply] Anton Shterenlikht 2008-08-07 02:00:12 PDT I saved the patch into /usr/ports/www/firefox3/work/mozilla/xpcom/glue/ns/nsTHashtable.h.patch Then I did # patch < nsTHashtable.h.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xpcom/glue/nsTHashtable.h b/xpcom/glue/nsTHashtable.h |--- a/xpcom/glue/nsTHashtable.h |+++ b/xpcom/glue/nsTHashtable.h -------------------------- Patching file nsTHashtable.h using Plan A... Hunk #1 succeeded at 157 (offset -6 lines). Hunk #2 succeeded at 355 (offset -6 lines). Hunk #3 succeeded at 365 (offset -6 lines). Hunk #4 succeeded at 375 (offset -6 lines). Hunk #5 succeeded at 387 (offset -6 lines). Hunk #6 succeeded at 396 (offset -6 lines). Hunk #7 succeeded at 408 (offset -6 lines). Hmm... Ignoring the trailing garbage. done # The error message is very similar, if not the same: gmake[5]: Entering directory `/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src' nsCookieService.cpp c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/storage -I../../../dist/include -I../../../dist/include/necko -I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h nsCookieService.cpp ../../../dist/include/xpcom/nsTHashtable.h: In static member function `static PRBool nsTHashtable<EntryType>::s_MatchEntry(PLDHashTable*, const PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]': ../../../dist/include/xpcom/nsTHashtable.h:334: instantiated from `PRBool nsTHashtable<EntryType>::Init(PRUint32) [with EntryType = nsCookieEntry]' nsCookieService.cpp:418: instantiated from here ../../../dist/include/xpcom/nsTHashtable.h:367: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type gmake[5]: *** [nsCookieService.o] Error 1 thanks anton Comment #5 [reply] Anton Shterenlikht 2008-08-07 05:08:01 PDT Also, in case it matters, the compiler versions are: # gcc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 # # gcc42 -v Using built-in specs. Target: alpha-portbld-freebsd6.3 Configured with: ./..//gcc-4.2-20080702/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local --program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.5 --with-gxx-include-dir=/usr/local/lib/gcc-4.2.5/include/c++/ --disable-libgcj --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc42 alpha-portbld-freebsd6.3 Thread model: posix gcc version 4.2.5 20080702 (prerelease) # I believe freebsd3 port is being built with the system compiler, i.e. 3.4.6. anton Comment #6 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-07 05:27:34 PDT In that case, I do not know how to fix this bug... I'm almost certain the error is bogus, since we know that the PLDHashEntryHdr* is the correct alignment (confirmed using sizeof()), but I don't know how to inform the compiler that this cast should be allowed. Comment #7 [reply] Mike Shaver 2008-08-07 05:42:08 PDT How do you confirm alignment with sizeof? Comment #8 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-07 05:56:30 PDT >From experiments, it seems that sizeof(struct) is always a multiple of the necessary alignment for that struct. The pldhash entry store is malloced (which has perfect alignment) and entries are on sizeof(struct) boundaries within the allocation, so I believe that in reality they are always correctly aligned. Shaver says: "I guess you want to cast via void*"... which makes me sad! " -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080818083712.GA1032>