I need to know if 32-bit or 64-bit perl is running my script.

[Anonymous Monk]

32-bit solaris used to have process start time at position 264 in psinfo. 64-bit has it at 332 (I'm sort of guessing on that.) How can I tell if my perl process is running under a 32-bit binary, or 64-bits?

(Bonus points for AIX.)

[BrowserUk]

Should work anywhere:

C:\test>\perl64\bin\perl -e"print length  pack 'P', -1"
8
C:\test>\perl32\bin\perl -e"print length pack 'P', -1"
4

[mbethke]

To see the userland code size that's a nice way. But if the kernel determines where stuff is placed in a struct and the kernel can run both 32- and 64-bit executables, you're still fuct. Plus some weird architectures like AS/400 (relevant for AIX) use 128bit pointers even on 32bit ALUs.

[BrowserUk]

But if the kernel determines where stuff is placed in a struct and the kernel can run both 32- and 64-bit executables, you're still fuct.

That is certainly not the case for Intel processors. Even running under 64-bit kernels; 32-bit processes only use 32-bit pointers.

Plus some weird architectures like AS/400 (relevant for AIX) use 128bit pointers even on 32bit ALUs.

I know naff all about AS/400, but since the original AS/400 hardware was 48-bit; and it has all been 64-bit for the last decade or so; one wonders whether the question is even relevant for such hardware?

[dave_the_m]

If you want the perl process's start time, then that's already available in $^T. If you want a different prcocess's start time, then the 32/64-bitness of the executing perl should be irrelevant (a system may be running a mixture of 32-bit and 64-bit executables). Unless the psinfo offset is determined not by the individual processes, but by the type of the kernel. If the latter, then its a while since I've used solaris, but IIRC, psrinfo(1) gives you that info.

Dave.

[flexvault]

AM,

I may be missing your point, but if you want to see if it's 32/64 bit Perl on AIX, try this:

 [path/]perl -V | grep 32    # or 64

and you will get something like this:

. . . -maix32        # or 64

This gives you the C compiler info for the Perl executable.

Regards...Ed

[Tux]

Why use external commands when everything and more is already available?

$ perl -V:ptrsize
ptrsize='8';
$ perl -MConfig -wE'say $Config{ptrsize}'
8
$ perl -MData::Peek -MConfig::Perl::V -we'DDumper (Config::Perl::V::my
+config ()->{config})'

Read more... (5 kB)

[flexvault]

Tux,

Very Nice!

but... something to keep in mind:

• You may not be able in install CPAN modules in a production system.

I tested the performance on a test system:

# *Your method* after installing 2 CPAN modules
 real   0m0.84s
 user   0m0.76s
 sys    0m0.008s

# *My method* calling Perl from the command line
 real   0m0.028s
 user   0m0.032s       # Note: I did this 3 times and 'user' > 'real' 
+was every time???
 sys    0m0.004s

Granted your routines providing a lot of information, but doing a 'system' call to get some specific information may not be that bad of a hit.

I'm still going to add this to my bag of tricks. Good job!

Regards...Ed

[mbethke]

That's nasty, I hope you're writing something that will abstract this away for others :) In C you could check if 0 == 1L<<32 but that would effectively identify your userland which IIRC doesn't have to match the kernel on Solaris. In Perl, even an interpreter running in 32bit userland can use 64bit ints so not even that works. I suppose the most reliable way would be to parse uname -a output somehow.

[Perlbotics]

When in Solarisland, ask Solaris (pflags).

This one is ultra-fragile, but decide yourself if you can use or expand it!

use strict;
use warnings;

#-- returns 32 or 64, or 0 in case of error 
#   optional argument: PID of another process; defaults to current PID
#   see also: http://docs.oracle.com/cd/E26502_01/html/E29030/pflags-1
+.html      (pflags)
#             http://docs.oracle.com/cd/E26502_01/html/E28556/proc-pro
+vider.html (psinfo_t section)
#   "...The pr_dmodel field is set to either PR_MODEL_ILP32, denoting 
+a 32bit process,
#       or PR_MODEL_LP64, denoting a 64bit process."
#
#   WARNING! Tested under Solaris 10/11 only!
#
sub solaris_bits {
        my $pid    = shift || $$;
        my $pflags = qx{LANG=C /usr/bin/pflags $pid 2>&1}; 

        #-- "data model" should be '_ILP32' or '_LP64'
        return  $pflags =~ /data model\s*=\s*\D*(\d+)/ms  ?  $1 : 0;
}


print "Bits (init): ", solaris_bits(1) || 'n/a' , "\n"; # PID==1 (need
+s privileges!)
print "Bits (self): ", solaris_bits()  || 'n/a' , "\n"; # PID==$$

However, when checking bit-width for the current perl process ($pid == $$), I would rather use BrowserUks pack() approach.
There is also Solaris::Procfs but the bug-reports indicate, that it doesn't compile in a 64-bit environment. Nice opportunity to make this module work again (wink).

[DrHyde]

I do something like this:

$ perl -e 'eval { my @foo;$foo[2**32]="1" } || warn("Not big enough\n"
+)'

That will warn with a 32-bit perl. However, the pointer size of an executable binary (and the libs it's linked against) doesn't necessarily tell you whether the OS is 32- or 64-bit. On many OSes (not sure about Solaris) a 32-bit binary can run on 32- or 64-bit OSes. Also beware that a perl with 32-bit pointers on a 32-bit OS can still, if compiled with the right options, have 64 bit integers and access large files.

[Tux]

What is wrong with using modules that already tackled that problem, like Proc::ProcessTable or Unix::Statgrab?

[Anonymous Monk]

Thanks for all of your help. $^T is especially exciting.

You've all stimulated the more general question, though: can the root user look at any random process's info and determine if it is running in 32 or 64 bit mode?

I like to think that something under the proc tree should tell me.

[Anonymous Monk]

I meant /proc, not proc tree.