n32 infinite recursion in __fixsfdi/__fixunssfdi:

[Manuel Bouyer]

Hello,
I've now another issue with HEAD and N32 userland. Some programs dump
core, with what looks like an infinite recursion in __fixsfdi/__fixunssfdi:

cuba# gdb /sbin/mount_tmpfs mount_tmpfs.core
Core was generated by `mount_tmpfs'.
Program terminated with signal 11, Segmentation fault.
#0 0x78658ed4 in __ltsf2 () from /lib/libc.so.12
(gdb) where
#0 0x78658ed4 in __ltsf2 () from /lib/libc.so.12
#1 0x785f422c in __fixsfdi () from /lib/libc.so.12
#2 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#3 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#4 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#5 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#6 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#7 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#8 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
[...]
#108009 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#108010 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#108011 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#108012 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
/dsk/l1/misc/bouyer/HEAD/src/external/gpl3/gdb/dist/gdb/utils.c:1162: internal-error: virtual memory exhausted: can't allocate 4420 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.


Any idea ? I see mknative have been re-run since netbsd-6 was branched,
I don't know how it affects libgcc_s.

[Manuel Bouyer]

Post by Manuel Bouyer
Hello,
I've now another issue with HEAD and N32 userland. Some programs dump
cuba# gdb /sbin/mount_tmpfs mount_tmpfs.core
Core was generated by `mount_tmpfs'.
Program terminated with signal 11, Segmentation fault.
#0 0x78658ed4 in __ltsf2 () from /lib/libc.so.12
(gdb) where
#0 0x78658ed4 in __ltsf2 () from /lib/libc.so.12
#1 0x785f422c in __fixsfdi () from /lib/libc.so.12
#2 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#3 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#4 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#5 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#6 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#7 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#8 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
[...]
#108009 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#108010 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
#108011 0x785f4254 in __fixsfdi () from /lib/libc.so.12
#108012 0x78758344 in __fixunssfdi () from /lib/libgcc_s.so.1
/dsk/l1/misc/bouyer/HEAD/src/external/gpl3/gdb/dist/gdb/utils.c:1162: internal-error: virtual memory exhausted: can't allocate 4420 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Any idea ? I see mknative have been re-run since netbsd-6 was branched,
I don't know how it affects libgcc_s.

Using the NetBSD 6.1.3 binary with HEAD libraries doesn't cause this error,
so I suspect the problem is with the compiler.
This is reproductible also with ntpdate and progress (I tested 6.1.3
binaries against HEAD libraries for both).

[Martin Husemann]

Post by Manuel Bouyer
Hello,
I've now another issue with HEAD and N32 userland. Some programs dump

Is your build very recent?
Sounds like libc/compile_rt lossage introduced ~yesterday.

Martin

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
Hello,
I've now another issue with HEAD and N32 userland. Some programs dump

Is your build very recent?
Sounds like libc/compile_rt lossage introduced ~yesterday.

I rebuilt today, possibly with an up to date libc (I probably updated all
of src/lib/ after fixing the problem in crtbegin yesterday).
I'll rebuild after updating all of src/ do see if this helps.

[Manuel Bouyer]

Post by Manuel Bouyer

Post by Martin Husemann

Post by Manuel Bouyer
Hello,
I've now another issue with HEAD and N32 userland. Some programs dump

Is your build very recent?
Sounds like libc/compile_rt lossage introduced ~yesterday.

I rebuilt today, possibly with an up to date libc (I probably updated all
of src/lib/ after fixing the problem in crtbegin yesterday).
I'll rebuild after updating all of src/ do see if this helps.

After a source update and full rebuild (from empty obj and destdir),
the problem seems to be fixed.

[Martin Husemann]

Post by Manuel Bouyer
After a source update and full rebuild (from empty obj and destdir),
the problem seems to be fixed.

I updated an alchemy (evbarm-el, o32) box today and it worked fine as
well (this was compiled with gcc 4.8.x).

Martin