Re: About gcc builtin atomics

[Mikael Pettersson]

On Sun, 17 Jun 2012 13:42:29 + (UTC), Thorsten Glaser  
wrote:
> Hi,
> 
> I was just randomly wondering whether it might still be possible
> to add __sync_* support to gcc-4.6 - earlier I've had a look at
> the relevant commits, and they depend on deep changes to the
> machine-independent code so that's a no-go.
> 
> I was wondering whether just adding one file from gcc-4.7 to the
> build and hooking it up in t-linux would work, considering gcc
> already emits externs for __sync_*_4() if it encounters use of
> such builtins in the code, because recently, I've taken some of
> that file and just added it ``inline'' to the one file using one
> of those functions, and it worked.
> 
> svn://gcc.gnu.org/svn/gcc/trunk/libgcc/config/m68k/linux-atomic.c
> is the file I was talking about.
> 
> Mikael, can that work, just adding those functions to (the static,
> as they're HIDDEN) libgcc, without patching gcc itself, in 4.6?

That could work.  You'll need to reassemble libgcc.a with the new
object file, and you'll need to replace the libgcc_s.so file that's
usually a symlink with a linker script that sources both the shared
and the static libgcc, as is already done for ARM and others.

IMO it's better to do this "properly" by modifying the gcc sources,
since that allows other gcc libraries (like libstdc++) and the test
suite to pick up the improved sync op support.  But for avoiding
compile errors in package rebuilds the above should suffice.

/Mikael

\begin{digression}
I actually began working on linux-atomic.c for m68k about 16 months
ago, basing it on the ARM one but using CAS rather than a syscall.
But I got regressions in the libgomp test suite I couldn't explain,
so I halted that project.  Now we know that aranym had a broken
CAS emulation :-(

I also did an implementation of "sync.md" for m68k in the gcc-4.6
code base, which added proper code generation support for sync ops,
rather than treating them as procedure calls.  (This was not a plain
backport from 4.7 due to technical differences between the pre-4.7
style sync ops and the 4.7+ style atomic ops.)  Again I got test suite
regressions (presumably due to the aranym CAS bug) so I didn't finish it.
\end{digression}


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20446.22554.69419.107...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Mon, 18 Jun 2012 20:40:40 + (UTC), Thorsten Glaser  
wrote:
> Mikael Pettersson dixit:
> 
> >That could work.
> 
> Does anyone have got a test programme for the atomic builtins,
> which could ideally test their behaviour at runtime too, if there
> is a way to get it tested deterministically? (As I admitted earlier,
> I'm lacking skills in the parallel programming area...)

I don't know of any test suites targeted to testing atomic primitives.
Maybe libatomic_ops has one?

I've always relied on gcc's c, c++, and libgomp test suites when
testing my attempts to implement atomics in gcc.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20448.10847.180213.68...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Thu, 21 Jun 2012 19:13:03 + (UTC), Thorsten Glaser  
wrote:
> /usr/bin/ld: nouveau_dri.so.test: hidden symbol `__sync_sub_and_fetch_4' in=
>  /usr/lib/gcc/m68k-linux-gnu/4.6/libgcc.a(linux-atomic.o) is referenced by =
> DSO
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> make[4]: *** [nouveau_dri.so] Error 1
> make[4]: Leaving directory `/tmp/buildd/mesa-8.0.3/build/dri/src/gallium/ta=
> rgets/dri-nouveau'
> 
> Mikael, I'm not familiar with special rules for hidden symbols,
> but then, the GNU world has been running at a much faster pace
> wrt. shared objects than the BSDs, so that's no surprise - do
> you have an advice what to do to not have such errors?

This linker issue is GCC PR40134.

As I mentioned before you need to replace the libgcc_s.so symlink
with a linker script.  Several gcc targets (at least powerpc, sh,
hppa, and arm) do so already because they have helpers in their
static libgcc that aren't present in their shared libgcc.

On the distro I'm using:
- on an i686 box:
  /usr/lib/gcc/i686-${vendor}-linux/4.6.3/libgcc_s.so is a symlink
  to /lib/libgcc_s.so.1
- on an arm box:
  /usr/lib/gcc/armv5tel-${vendor}-linux-gnueabi/4.6.3/libgcc_s.so
  is a linker script containing
==snip==
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libgcc_s.so.1 libgcc.a )
==snip==

You should update gcc/config.gcc to append t-slibgcc-libgcc to
tmake_file for the m68k-*-linux* target before building gcc, and
then adjust whatever your gcc source package does to create the
libgcc_s.so linker script for powerpc/arm to also happen for m68k.

See the patch revisions referenced by GCC PR40134.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20452.16784.29290.172...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Fri, 22 Jun 2012 18:37:52 + (UTC), Thorsten Glaser  
wrote:
> Mikael Pettersson dixit:
> 
> >As I mentioned before you need to replace the libgcc_s.so symlink
> >with a linker script.  Several gcc targets (at least powerpc, sh,
> >hppa, and arm) do so already because they have helpers in their
> >static libgcc that aren't present in their shared libgcc.
> 
> I tried to validate this before sacrificing three days in building
> gcc, and could not get it to work.
> 
> # cat /usr/lib/gcc/m68k-linux-gnu/4.6/libgcc_s.so
> GROUP ( /lib/m68k-linux-gnu/libgcc_s.so.2 libgcc.a )
> 
> I then rebuilt libstdc++.so from the -pic package:
> 
> gcc -shared-libgcc -shared -Wl,--whole-archive /usr/lib/gcc/m68k-linux-gnu/=
> 4.6/libstdc++_pic.a -Wl,--no-whole-archive -lm -lc -lgcc_s -Wl,-O1 -Wl,-z -=
> Wl,relro -Wl,--version-script=3D/usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++_p=
> ic.map -Wl,-soname -Wl,libstdc++.so.6 -o libstdc++.so.6.0.16
> 
> Then I replaced the symlink:
> 
> lrwxrwxrwx 1 root root 84 Jun 22 18:29 /usr/lib/gcc/m68k-linux-gnu/4.6/libs=
> tdc++.so -> /tmp/buildd/mesa-8.0.3/build/dri/src/gallium/targets/dri-nouvea=
> u/libstdc++.so.6.0.16*
> 
> (Erm well, yes, I just did it in $PWD for easiness.)
> 
> But linking still fails:
> 
> # g++ -Wall -g -O2 -Wall -Wmissing-prototypes -std=3Dc99 -fno-strict-aliasi=
> ng -fno-builtin-memcmp -Wall -g -O2  -fPIC   -D_GNU_SOURCE -DPTHREADS -DTEX=
> TURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING=
>  -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D=
> 1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI=
> 2 -fvisibility=3Dhidden -o nouveau_dri.so.test ../../../../src/mesa/drivers=
> /dri/common/dri_test.o nouveau_dri.so.tmp  ../../../../src/mesa/libmesa.a  =
> -ldrm   -lexpat -lm -lpthread -ldl -ldrm_nouveau   -Wl,-t
> /usr/bin/ld: mode m68kelf
> /usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/crt1.o
> /usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/crti.o
> /usr/lib/gcc/m68k-linux-gnu/4.6/crtbegin.o
> =2E./../../../src/mesa/drivers/dri/common/dri_test.o
> nouveau_dri.so.tmp
> -ldrm (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libdrm.so)
> -lexpat (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libexpat.s=
> o)
> /lib/m68k-linux-gnu/libpthread.so.0
> -ldl (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libdl.so)
> -ldrm_nouveau (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libd=
> rm_nouveau.so)
> -lstdc++ (/usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++.so)
> -lm (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libm.so)
> /lib/m68k-linux-gnu/libgcc_s.so.2
> (/usr/lib/gcc/m68k-linux-gnu/4.6/libgcc.a)linux-atomic.o
> /lib/m68k-linux-gnu/libc.so.6
> (/usr/lib/m68k-linux-gnu/libc_nonshared.a)elf-init.oS
> /lib/m68k-linux-gnu/ld.so.1
> /lib/m68k-linux-gnu/libgcc_s.so.2
> /usr/lib/gcc/m68k-linux-gnu/4.6/crtend.o
> /usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/crtn.o
> /usr/bin/ld: nouveau_dri.so.test: hidden symbol `__sync_sub_and_fetch_4' in=
>  /usr/lib/gcc/m68k-linux-gnu/4.6/libgcc.a(linux-atomic.o) is referenced by =
> DSO
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> 
> However, ./libstdc++.so.6.0.16 contains the symbols, a nm(1) shows:
> 000ab7ba t __sync_sub_and_fetch_4
> Stripping ./libstdc++.so.6.0.16 does not help either. So I=E2=80=99m not
> very convinced I=E2=80=99m seeing the same issue.
> 
> Interestingly enough, an nm -D on the original libstdc++.so did
> not reveal any symbol reference to __sync_sub_and_fetch_4 either.
> My first reading of the error message let me think that the problem
> was that the DSO to be *made* (nouveau_dri.so.test) uses them.
> Maybe DSOs are not supposed to include code from libgcc.a at all?
> Or maybe PIC is needed?

Check the input object files in the above link step to see which one
brings in the reference to __sync_sub_and_fetch_4.  My suspicion is
that it's nouveau_dri.so.tmp, libdrm_nouveau.so, or libdrm.so; if so,
then that .so file must be rebuilt against the new libgcc_s.so linker
script.

.so files can include code from libgcc.a just fine, but every such
.so file must be produced by linking it explicitly against both the
shared and the static libgcc.

The occurrence in libstdc++.so is a private definition: it's used
for libstdc++.so's own references but cannot be used by other .so
files

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20454.1391.679986.405...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Mon, 25 Jun 2012 22:14:03 + (UTC), Thorsten Glaser  
wrote:
> Mikael Pettersson dixit:
> 
> >Now we know that aranym had a broken
> >CAS emulation :-(
> 
> Those problems are gone now though?

I hope so.  I've updated my previous sync implementations for m68k
(both the linux-atomic.c one and the sync.md one) and I'm testing
them again with aranym-0.9.13 + a few backports from cvs head.

> >I've always relied on gcc's c, c++, and libgomp test suites when
> >testing my attempts to implement atomics in gcc.
> 
> *sigh* I guess I=E2=80=99ll port the patches to doko=E2=80=99s latest uploa=
> d and
> build that withOUT nocheck, but the results won=E2=80=99t be in time for
> the freeze then. libdrm and mesa built from unchanged sources now,
> though. Should I submit the patches to doko right now, or do we
> want to chance me maintaining gcc-4.6 in unreleased until after
> the unfreeze?
> 
> What, in particular, should I look out for in the testsuite?
> (I imagine that many things would be broken, independent of
> this change.)

Many things are indeed failing in the test suite on m68k.  What you
should do is to make two full bootstraps and regression test runs,
first with a baseline version (I use FSF vanilla, you might want to
use Debian's common gcc without your patch), and then with the
baseline plus your patch.  Then you 'diff' the test suite summary
files from the two runs and analyze any new failures.

>  Maybe I should just mail the entire build log
> to the list? (Unless someone can figure out how I can upload
> it to debian-ports.org=E2=80=A6 and I whether my MTA can deal with
> that =E2=80=93 probably on a good-connected machine.)

Build logs aren't interesting unless they show build failures.
Proper test suite results are produced as follows:

0. prep sources, mkdir objdir, cd objdir, /path/to/source/configure ...
   as usual for any gcc build
1. make bootstrap
2. make -k check (don't forget the -k!)
3. make mail-report.log

The last step scans the detailed test suite logs and produces a
summary that can be diffed against a previous one, or mailed to
gcc-testresults (but don't do that for a heavily-modified vendor
gcc, perhaps Debian has its own place for posting test suite
results?)

On the Core i7-970 (3.2GHz, 6 cores, Westmere) that hosts my
aranym VMs, a VM can do a gcc 4.6 bootstrap plus test suite run
in slightly over 2.5 days, but that's with --enable-languages=c,c++
and with two patches to reduce 'genattrtab' overheads; with all
languages and without the genattrtab patches it might take 4-5 days.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20457.28630.690895.880...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Tue, 26 Jun 2012 10:48:02 +0200, Geert Uytterhoeven  
wrote:
> On Tue, Jun 26, 2012 at 10:26 AM, Thorsten Glaser  wrote:
> > Geert Uytterhoeven dixit:
> >
> >>Even if they're fixed on ARAnyM, this doesn't fix the CAS problems on sev=
> eral
> >>instantations of real hardware
> >
> > Right. That=E2=80=99s why we use the syscall always. OK.
> > (On Linux, but not on e.g. FreeMiNT.)
> 
> FreeMiNT on which hardware?
> 
> arch/m68k/Kconfig.cpu has:
> 
> config RMW_INSNS
> bool "Use read-modify-write instructions"
> depends on ADVANCED
> ---help---
>   This allows to use certain instructions that work with indivisible
>   read-modify-write bus cycles. While this is faster than the
>   workaround of disabling interrupts, it can conflict with DMA
>   ( = direct memory access) on many Amiga systems, and it is also said
>   to destabilize other machines. It is very likely that this will
>   cause serious problems on any Amiga or Atari Medusa if set. The only
>   configuration where it should work are 68030-based Ataris, where it
>   apparently improves performance. But you've been warned! Unless you
>   really know what you are doing, say N. Try Y only if you're quite
>   adventurous.

I'd really like to see a more detailed description of the platform
issue.  For starters,

1. "conflict with DMA" is very vague, what exactly are the symptoms?
2. "said to destabilize other machines" is also very vague, details?
3. are the 030s OK everywhere or just on Atari? what about 040s?
4. the option description says nothing about user-space; as the gcc
   code is for shared variables in normal user-space program memory
   rather than e.g. accessing control registers in MMIO space, it's
   entirely possible that CAS is OK in user-space (at least as long
   as mmap of MMIO space is disallowed)

OTOH, if CAS is provably unsafe in user-space for a sizeable portion
of the Linux/m68k HW base, then the kernel should IMO provide a
vsyscall page with at least CAS and DCAS/CAS64 entry points (doing
CAS or DCAS when possible, trapping otherwise), and possibly also
CAS.W and CAS.B entries.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20457.33061.522281.794...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Tue, 26 Jun 2012 12:29:49 + (UTC), Thorsten Glaser  
wrote:
> >OTOH, if CAS is provably unsafe in user-space for a sizeable portion
> >of the Linux/m68k HW base, then the kernel should IMO provide a
> >vsyscall page with at least CAS and DCAS/CAS64 entry points (doing
> 
> And TLS!
> 
> So who's going to be writing it? ;-)

I saw Andreas Schwab's comment last month about supporting get_thread_area
via a vdso , but
given the m68k ISA I don't see any way of doing that except:

a) issuing a syscall, as is done today, or
b) having the kernel update a reserved location in a process' address
   space whenever a thread in that process is resumed

The latter is what Linux/ARM does on pre-ARMv6 processors, but it entails:

- having a vsyscall page at a fixed location (vdso is too horrible), and
- updating a long word in it in each switch_to()
- SMP is initially prohibited, the get_thread_area entry needs to be a
  proper function, so that a future SMP-capable system can be allowed,
  either by reverting to doing a syscall, or by using an extended ISA
  where the TLS pointer _can_ be retrieved directly in user-space

I could probably implement something like that, but I'm not sure how
the kernel maintainers would feel about a per-process vsyscall page...

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20457.53942.451105.716...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Tue, 26 Jun 2012 18:14:39 + (UTC), Thorsten Glaser  
wrote:
> Mikael Pettersson dixit:
> 
> >- having a vsyscall page at a fixed location (vdso is too horrible), and
> >- updating a long word in it in each switch_to()
> 
> sounds ok to me
> 
> >- SMP is initially prohibited, the get_thread_area entry needs to be a
> >  proper function, so that a future SMP-capable system can be allowed,
> 
> Do we need *MP on m68k at all?

Depends on your perspective.  I know commonly available HW isn't SMP,
but the architecture is SMP-capable, there have been some MP machines
(DIAB produced some with 030 and 040, and I've seen VMEbus boards with
dual 040 or 060).  And a dual or quad core m68k for an FPGA should
be doable given that both single-core m68k and multi-core non-m68k
FPGAs already exist.

I'm not suggesting that SMP HW will be available any time soon,
but I'd rather keep the option open than design an ABI that cannot
work at all in such a system.  The get_thread_area vsyscall would
still be orders of magnitude faster than the current syscall.

> >I could probably implement something like that, but I'm not sure how
> >the kernel maintainers would feel about a per-process vsyscall page...
> 
> Not a kernel maintainer, but isn't that the whole point, to have the
> page per-process so no kernel mode round-trips are required?

Yes, but there's also a cost in that there's one more store on every
context switch, and every page table must have one additional entry.

Security-centric people dislike vsyscall pages and prefer vdsos
since their address-space placements can be randomized, but that
also makes vdsos slower to access.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20458.50642.999507.376...@pilspetsen.it.uu.se

Re: ARAnyM VMs with Debian hanging at 100% CPU usage

[Mikael Pettersson]

On Thu, 2 Aug 2012 17:13:49 + (UTC), Thorsten Glaser  wrote:
> Geert Uytterhoeven dixit:
> 
> >If I'm not mistaken, the warning was just a false positive, so I didn't 
> >submit
> >the fix for stable?
> 
> Was it just the warning issued, or was there really something
> wrong with interrupt handling on Atari, that's the question
> here (which *I* cannot answer). I was under the impression it
> fixed a warning, too, but Andreas' mail suggested it may have
> been a fix for interrupt handling or somesuch...

Although the kernel warning turned out to be a false positive, the
underlying cause was a real bug with real consequences: a CPU-bound
process could block nfeth interrupts for unbounded periods of time.

(I did describe that in the patch message, but perhaps I didn't
emphasize it enough.)

I've seen it happen too, with gcc bootstraps being killed because log
output via a pipe and nfeth couldn't be drained entually SIGPIPEing
the builds.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20507.34375.305618.227...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Sat, 1 Dec 2012 12:33:06 + (UTC), Thorsten Glaser  wrote:
> Mikael Pettersson dixit:
> 
> >and with two patches to reduce 'genattrtab' overheads; with all
> 
> I think I asked already, but again, pretty please, care to share? ;-)

Sure, you can find three attrtab speedup patches I've backported from
gcc-4.8/trunk to gcc-4.6.3 in:
<http://user.it.uu.se/~mikpe/linux/patches/gcc/gcc-4.6.3-patches/patches0/>.

Two are generic, one is m68k-specific.  The m68k-specific one makes a
huge difference, even when building a cross-compiler on a fast x86_64.
I haven't measured the other two but they probably help a bit too.
All three have been thoroughly regression-tested on multiple archs
(m68k, armv5te, x86_64, sparc64, powerpc64).

I also have corresponding patches for gcc-4.7.2, if you want them.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20666.5342.988771.826...@pilspetsen.it.uu.se

Re: About gcc builtin atomics

[Mikael Pettersson]

On Sat, 1 Dec 2012 14:39:32 + (UTC), Thorsten Glaser  wrote:

> >Sure, you can find three attrtab speedup patches I've backported from
> >gcc-4.8/trunk to gcc-4.6.3 in:
> >.
> 
> Oh, you're great, thanks!
> 
> All of them have been applied in trunk?

Yes, they are revisions 187181, 187234, and 187714 from gcc trunk svn.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20666.9680.887054.698...@pilspetsen.it.uu.se

Re: [erlang-questions] Erlang in Debian on m68k architecture

[Mikael Pettersson]

Sergei Golovan writes:
 > Hi!
 > 
 > As one can see, erlang Debian package (R11B-2 relese, 11.b.2 in Debian
 > versioning) fails to build on m68k now
 > (http://buildd.debian.org/fetch.cgi?&pkg=erlang&ver=1%3A11.b.2-4&arch=m68k&stamp=1167824208&file=log).
 > 
 > After some research, we've found that erlang relies on the alignment
 > of some global variable. The following patch fixes it:
 > --
 > --- erlang-11.b.2.orig/erts/emulator/beam/binary.c
 > +++ erlang-11.b.2/erts/emulator/beam/binary.c
 > @@ -31,7 +31,7 @@
 >  #include "erl_bits.h"
 > 
 >  Uint erts_allocated_binaries;
 > -erts_mtx_t erts_bin_alloc_mtx;
 > +erts_mtx_t erts_bin_alloc_mtx __attribute__ ((aligned (4)));
 > 
 >  void
 >  erts_init_binary(void)
 > --
 > 
 > So, the question is the following: Are global variables supposed to be
 > always aligned? Is this a bug in GCC that it doesn't align the
 > variable?

Definitely smells like a toolchain bug to me. In this case, since you've
enabled threads, erts_mtx_t is a properly declared struct type containing
among other things a pthread_mutex_t, an int, and a couple of pointers.
I don't remember how strict M68K is about alignment, but presumably it wants
non-arbitrary alignment for word-sized fields, especially perhaps if they're
used for atomic accesses.

The error could be in gcc, gas, ld, or even libc.

As GDB session on the core dump should tell us more about the location
of the crash, the failing instruction, and what data it tried to access.

/Mikael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [erlang-questions] Erlang in Debian on m68k architecture

[Mikael Pettersson]

Sergei Golovan writes:
 > On 1/25/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote:
 > > Definitely smells like a toolchain bug to me. In this case, since you've
 > > enabled threads, erts_mtx_t is a properly declared struct type containing
 > > among other things a pthread_mutex_t, an int, and a couple of pointers.
 > > I don't remember how strict M68K is about alignment, but presumably it 
 > > wants
 > > non-arbitrary alignment for word-sized fields, especially perhaps if 
 > > they're
 > > used for atomic accesses.
 > >
 > > The error could be in gcc, gas, ld, or even libc.
 > >
 > > As GDB session on the core dump should tell us more about the location
 > > of the crash, the failing instruction, and what data it tried to access.
 > 
 > Here are two backtraces, without and with DEBUG defined. If you need
 > some additional info, I'll try to give it also
...
 > With debug.
 > -
 > (gdb) bt
 > #0  0xc0103522 in kill () from /lib/libc.so.6
 > #1  0xc004a87e in pthread_kill () from /lib/libpthread.so.0
 > #2  0xc004a8b6 in raise () from /lib/libpthread.so.0
 > #3  0xc0103380 in raise () from /lib/libc.so.6
 > #4  0xc0104266 in abort () from /lib/libc.so.6
 > #5  0x8009b534 in et_abort (expr=0x800fb643 "_is_aligned(x)",
 > file=0x800fa37f "beam/erl_lock_check.c", line=1018) at
 > beam/erl_term.c:45
 > #6  0x8009c1b4 in checked_make_boxed (x=0x0, file=0x800fa37f
 > "beam/erl_lock_check.c", line=1018) at beam/erl_term.c:123
 > #7  0x80092bca in erts_lc_init_lock (lck=0x8015abe2, name=0x800f0178
 > "binary_alloc", flags=0) at beam/erl_lock_check.c:1018
 > #8  0x800504c0 in erts_mtx_init (mtx=0x8015abba, name=0x800f0178
 > "binary_alloc") at beam/erl_threads.h:249
 > #9  0x800731e6 in erts_init_binary () at beam/binary.c:40
 > #10 0x8002d85c in erl_init () at beam/erl_init.c:211
 > #11 0x8002e568 in erl_start (argc=37, argv=0xe58c) at beam/erl_init.c:907
 > #12 0x8001a6fe in main (argc=37, argv=0xe584) at sys/unix/erl_main.c:28
 > -

What's happening is that an embedded Eterm field in the mutex,
placed there and used by the lock checker, isn't word-aligned,
which triggers an abort() in make_boxed(). In your non-debug
GDB trace this error went unnoticed but later on _seriously_
broke the GC.

The problem is still one of alignment. It seems that your M68K
toolchain doesn't align

struct { int x; } var;

to a 32-bit boundary. Whether that is the bug, or whether the
lock checker's alignment-of-static-data assumption is the bug,
I cannot tell until someone sends me a pointer to the M68K Linux
(or SVR4) ABI document.

/Mikael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [erlang-questions] Erlang in Debian on m68k architecture

[Mikael Pettersson]

Sergei Golovan writes:
 > On 1/25/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote:
 > > The problem is still one of alignment. It seems that your M68K
 > > toolchain doesn't align
 > >
 > > struct { int x; } var;
 > >
 > > to a 32-bit boundary. Whether that is the bug, or whether the
 > > lock checker's alignment-of-static-data assumption is the bug,
 > > I cannot tell until someone sends me a pointer to the M68K Linux
 > > (or SVR4) ABI document.
 > 
 > Then I would like to ask another question: Are there other variables
 > in erlang, which must be aligned to a 32-bit boundary? Or fixing
 > erts_bin_alloc_mtx alignment is sufficient?

There are many many many places where alignment is required,
and where incorrect alignment could cause almost random and
impossible to debug problems.

It is possible to enforce alignment with directives, the problem
is locating all the relevant places, and to ensure that alignment
directives don't cause unexpected internal padding. (Yes there are
assumptions about that as well.)

Unless you're dying to use Erlang on M68K, don't bother.

/Mikael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [pkg-boost-devel] Bug#719484: boost1.54: FTBFS

[Mikael Pettersson]

On Sun, 8 Sep 2013 07:21:40 + (UTC), Thorsten Glaser  wrote:
> Steve M. Robbins dixit:
> 
> >Interesting, but this is an entirely different bug.  Also, this new bug is=
>  in=20
> >gcc, not boost.
> 
> Sorry, right. I=E2=80=99m just amazed that the boost compilation is
> still continuing, and replied to the mail =E2=80=9Cthread=E2=80=9D we alrea=
> dy
> had so we have the information in one place.
> 
> I=E2=80=99ll follow this up on debian-68k@l.d.o for now, so you=E2=80=99re
> not =E2=80=9Cspammed=E2=80=9D with this particular thing.
> 
> Mikael: I could reproduce this with a crosscompiler with
> -g -O3 -fPIC where -fPIC is the culprit. Lowering to -O1
> also let us get rid of the ICE whereas removing -g had
> no effect, so the minimum to trigger it is -O2 -fPIC.

Please see 
for the upstream bug entry I've opened.  There is a reduced
test case there, an analysis of the bug, and two possible
patches.  I need to test the last patch extensively before
submitting it -- so don't use it outside of private testing
environments please.

The bug is very very sensitive to seemingly irrelevant details
in the source code being compiled.  You should be able to work
around it by tweaking optimization levels slightly.

/Mikael


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21040.50549.37535.833...@pilspetsen.it.uu.se

Re: [pkg-boost-devel] Bug#719484: boost1.54: FTBFS

[Mikael Pettersson]

Thorsten Glaser writes:
 > Steve M. Robbins dixit:
 > 
 > >Interesting, but this is an entirely different bug.  Also, this new bug is 
 > >in 
 > >gcc, not boost.
 > 
 > Sorry, right. I’m just amazed that the boost compilation is
 > still continuing, and replied to the mail “thread” we already
 > had so we have the information in one place.
 > 
 > I’ll follow this up on debian-68k@l.d.o for now, so you’re
 > not “spammed” with this particular thing.
 > 
 > Mikael: I could reproduce this with a crosscompiler with
 > -g -O3 -fPIC where -fPIC is the culprit. Lowering to -O1
 > also let us get rid of the ICE whereas removing -g had
 > no effect, so the minimum to trigger it is -O2 -fPIC.
 > 
 > bye,
 > //mirabilos

The GCC ICE bug is now fixed on GCC trunk by r204224, see
.
That patch backports trivially to gcc-4.8.2 and fixes the ICE
there too.

I'll try to get it into the gcc-4.8.3 release, but that's about
half a year or so away.

I've tested it extensively on m68k, x86_64, armv5tel, sparc64, and
powerpc64 without problems.

/Mikael


--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21105.30482.905267.701...@gargle.gargle.howl

Re: m68k FPU emulation: Unimplemented instruction

[Mikael Pettersson]

Thorsten Glaser writes:
 > Ingo Jürgensmann dixit:
 > 
 > > echo line to know which module is currently compiled) you might find the 
 > > module
 > > in question that generates that FPU error and investigate further then.
 > 
 > It’s not an error. Python (rightfully) runs some FPU instruction,
 > it just happens to be one the FPU emulator lacks, because it’s
 > incomplete.
 > 
 > Maybe we can have a GCC -m* flag that tells it to not emit those
 > instructions? (Maybe call library functions then or something.)

FLOGN was implemented in HW on 68881/2, but traps as unimplemented
on 040/060.  GCC cannot generate it, but  contains some
functions that emit it via inline asm().  Dunno about GLIBC.

I suggest extending the kernel's FPU emulator to handle it.

/Mikael


--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21133.53318.820247.147...@gargle.gargle.howl