I just wanted to run this by here and see if anyone else has seen or heard of this before I go digging any deeper and trying to file a bug with someone somewhere.

The gist of the issue seems to be that the perl v5.8.5 on an up to date SuSE 9.2 machine, running on an x86_64 architecture, seems to be using the wrong syscall numbers from its *.ph files, which breaks syscall() pretty much completely.

I found this out because I had a relatively simple perl script that used to work fine (on both 32 and 64 bit x86 platforms), which was using syscall() to call statfs(). When I deployed this script on an x86_64 SuSE 9.2 box for the first time, it segfaulted right around the time of the syscall(). strace revealed that it wasn't actually calling statfs() at all, but rather "sysinfo()", a completely different system call.

Further digging revealed that on 32-bit ix86 platforms, statfs() is system call number 99. On x86_64, statfs() is 137, and sysinfo() is at 99. So clearly, my x86_64 perl is trying to use 32-bit syscall numbers when it shouldn't be.

On other x86_64 installations with older but working 5.8.x versions of perl, /usr/lib/perl5/.../_h2ph_pre.ph contains (among other things):

unless (defined &__x86_64__) { sub __x86_64__() { 1 } }
On the machine giving issues, this is replaced by:
unless (defined &__amd64__) { sub __amd64__() { 1 } }

However, /usr/lib/perl5/.../asm/unistd.ph on both installations contain basically the same code:

if(defined(&__x86_64__)) { require 'asm-x86_64/unistd.ph'; } else { require 'asm-i386/unistd.ph'; }

So on the erroneous SuSE 9.2 x86_64 perl5.8.5 setup, since _h2ph_pre.ph defines __amd64__ instead of defining __x86_64__, but asm/unistd.ph is still looking for __x86_64__, the result is that it picks up the asm-i386 version of unistd, containing syscall numbers that are not correct for this architecture.

I'm not really sure at this point in time whether whatever bug this is (probably back at perl compilation time) lies in Perl 5.8.5, or in some particulars of the underlying gcc/glibc setup in SuSE 9.2, or is just a bug in how SuSE built this particular rpm of perl.

I haven't been able to google up any reference to anyone else having the same problem though, and I can't see how that would go unnoticed (am I the only person who uses syscall()? ). I peeked inside a Fedora Core 3 RPM for perl 5.8.5 and it seemed to be showing the exact same problem.

So, has anyone else run into this, and do you know the source of it and/or know why vendors haven't patched themselves out of this problem?


In reply to 5.8.5 x86_64 syscall issues? by ph713

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.