GNU bug report logs - #45214
guile segfaults on 32-bit big-endian targets

Previous Next

Package: guile;

Reported by: John Paul Adrian Glaubitz <glaubitz <at> physik.fu-berlin.de>

Date: Sat, 12 Dec 2020 21:27:01 UTC

Severity: normal

Full log


Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John David Anglin <dave.anglin <at> bell.net>
To: John Paul Adrian Glaubitz <glaubitz <at> physik.fu-berlin.de>, bug-guile <at> gnu.org
Cc: Helge Deller <deller <at> gmx.de>,
 Michael Karcher <debian <at> mkarcher.dialup.fu-berlin.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: guile segfaults on 32-bit big-endian targets
Date: Sat, 12 Dec 2020 17:44:06 -0500
On 2020-12-12 5:30 p.m., John David Anglin wrote:
> On 2020-12-12 5:21 p.m., John David Anglin wrote:
>> On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
>>> I assume the crash has got something to do how values are packed and unpacked
>>> into the SCM object type. I have not been able to find the problem yet myself,
>>> unfortunately which is why I am reporting this issue here.
>> I see this in scm.h:
>>
>> /* The 0?: constructions makes sure that the code is never executed, and
>>    that there is no performance hit.  However, the alternative is
>>    compiled, and does generate a warning when used with the wrong
>>    pointer type.  We use a volatile pointer type to avoid warnings from
>>    clang.
>>
>>    The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)'
>>    statements, so for them type-checking is disabled.  */
>> # if defined __DECC || defined __HP_cc
>> #  define SCM_UNPACK(x) ((scm_t_bits) (x))
>> # else
>> #  define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
>> # endif
> Also just before, there is:
> /* But as external interface, we define SCM, which may, according to the
>    desired level of type checking, be defined in several ways.  */
> #if (SCM_DEBUG_TYPING_STRICTNESS == 2)
>   typedef union SCM { struct { scm_t_bits n; } n; } SCM;
> # define SCM_UNPACK(x) ((x).n.n)
> # define SCM_PACK(x) ((SCM) { { (scm_t_bits) (x) } })
> #elif (SCM_DEBUG_TYPING_STRICTNESS == 1)
> /* This is the default, which provides an intermediate level of compile
>    time type checking while still resulting in very efficient code.  */
>   typedef struct scm_unused_struct { char scm_unused_field; } *SCM;
>
> The fault on hppa appears to be at strictness 1.
Guess, I should have copied the whole bit:

The last option is:
#else
/* This should be used as a fall back solution for machines on which
   casting to a pointer may lead to loss of bit information, e. g. in
   the three least significant bits.  */
  typedef scm_t_bits SCM;
# define SCM_UNPACK(x) (x)
# define SCM_PACK(x) ((SCM) (x))
#endif

I think strictness 1 may be problematic on hppa.

Dave

-- 
John David Anglin  dave.anglin <at> bell.net





This bug report was last modified 3 years and 253 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.