Re: gcc 4.x.x on SLES 9
a crude wrapper around 'make' and the standard recipe. But it does not lend itself to multiple versions of a package the way /usr/opt does. I hope this helps. -- R; On Tue, Jan 12, 2010 at 10:09, rui guidevelo...@gmail.com wrote: Thanks a lot Richard and Mark for such a detailed explanation. I am using the /usr/opt scheme to build gcc . However, couple of queries: Can i use the second scheme for any version of gcc, as currently its working on 4.3.2? Also, when you said that the first scheme will update most other packages IN PLACE, what do you mean by that? Did you ou mean to say that the binutils will be replaced, but the gcc wouldn't be? I like the first scheme, looks like it will work on all platforms with all versions of gcc, but can you clear the INPlace thing and does it have any consequences on the system? Regards, Raja On Sat, Jan 9, 2010 at 6:02 PM, Richard Troth vmcow...@gmail.com wrote: Building GCC is not difficult, but is time consuming. (MOST of the time is simply letting the build run while you go off and have a cup of coffee ... or a four course meal ... and dessert ... and take in a movie.) You will, of course, need a fully functional development environment before you can [re]build GCC. When it works, it is mostly unattended. When it doesn't work, you will have to take the time and figure out what broke. (Maybe you simply need to upgrade some other support utility. Who knows?) YES, you can have two versions of GCC on the same system. No problem! What you must do is have them in different locations. I use two schemes for building GCC, as follows, BOTH of which place GCC apart from the usual locations. Both of them will automagically download the GCC source for you. *** Using CSCRATCH to build GCC *** I often use this in-place build scheme which includes GCC (and BINUTILS, which you may also want to upgrade). It happens that the scheme I call CSCRATCH places GCC (and BINUTILS) under /opt/gcc rather than under /usr, so your old compiler would still be available. (And would in fact be the default.) Be aware that this scheme will replace most other packages IN PLACE. The fact that it relocates GCC is a happy coincidence that I won't elaborate on today. It is presently doing GCC 4.3.2. If you have a machine, which already has a compiler, you are welcome to try ... mkdir /tmp/csc cd /tmp/csc wget http://www.casita.net/pub/csc/makefile make gcc.mk make gcc.src make gcc.cfg make gcc.exe sudo make gcc.ins Then to run the new compiler, set it first in command search ... PATH=/opt/gcc/bin:$PATH ; export PATH You may want to do the same for BINUTILS which is at the 2.18.50.0.6 level. (And also lands safely under /opt/gcc.) *** Using /usr/opt to build GCC *** I also often use a non-intrusive scheme for building packages, including GCC, which lets you isolate things from the operating system. (So it does not break your box out of DPKG or RPM management.) Someone at Rice University came up with the basic idea years ago, and I have come to rely on it heavily. I found the build logic for GCC 4.3.2 for this scheme and uploaded it to the web. /usr/opt by design keeps everything AWAY FROM the operating system, so here too your old compiler would still be available. (And would again still be the default.) There are more steps (than with CSCRATCH), but this is a much more open-ended solution. mkdir /tmp/gcc-4.3.2 cd /tmp/gcc-4.3.2 wget http://www.casita.net/pub/gcc/gcc-4.3.2.mak cp -p gcc-4.3.2.mak makefile wget http://www.casita.net/pub/setup.sh cp -p setup.sh setup chmod a+rx setup make source make config make sudo mkdir -m 1777 /usr/opt make install ./setup Again, to run the new compiler, make it first in your command search ... PATH=/usr/opt/gcc/bin:$PATH ; export PATH You may want to do the same with binutils-2.18.50.0.9. I do not know how well a home-grown GCC will behave w/r/t your mixed 32-bit and 64-bit environment. Personally, I would use one of the above methods and then rigorously test the stuff built by the new GCC. (Most of the libraries are outside of compiler space.) Rigorous testing is standard operating procedure, yes? :-) -- R; On Fri, Jan 8, 2010 at 11:26, rui guidevelo...@gmail.com wrote: Hi all, I am looking for gcc 4.2 onwards on sles9 x86_64. Can I get a prebuilt gcc or do i have to build it myself? if building is the way to go, what should be the configuration options? I would like GCC to have 64 bit libs - having 32 bit libs is useful, but not necessary. Regards, Raja
Re: gcc 4.x.x on SLES 9
Thanks a lot Richard and Mark for such a detailed explanation. I am using the /usr/opt scheme to build gcc . However, couple of queries: Can i use the second scheme for any version of gcc, as currently its working on 4.3.2? Also, when you said that the first scheme will update most other packages IN PLACE, what do you mean by that? Did you ou mean to say that the binutils will be replaced, but the gcc wouldn't be? I like the first scheme, looks like it will work on all platforms with all versions of gcc, but can you clear the INPlace thing and does it have any consequences on the system? Regards, Raja On Sat, Jan 9, 2010 at 6:02 PM, Richard Troth vmcow...@gmail.com wrote: Building GCC is not difficult, but is time consuming. (MOST of the time is simply letting the build run while you go off and have a cup of coffee ... or a four course meal ... and dessert ... and take in a movie.) You will, of course, need a fully functional development environment before you can [re]build GCC. When it works, it is mostly unattended. When it doesn't work, you will have to take the time and figure out what broke. (Maybe you simply need to upgrade some other support utility. Who knows?) YES, you can have two versions of GCC on the same system. No problem! What you must do is have them in different locations. I use two schemes for building GCC, as follows, BOTH of which place GCC apart from the usual locations. Both of them will automagically download the GCC source for you. *** Using CSCRATCH to build GCC *** I often use this in-place build scheme which includes GCC (and BINUTILS, which you may also want to upgrade). It happens that the scheme I call CSCRATCH places GCC (and BINUTILS) under /opt/gcc rather than under /usr, so your old compiler would still be available. (And would in fact be the default.) Be aware that this scheme will replace most other packages IN PLACE. The fact that it relocates GCC is a happy coincidence that I won't elaborate on today. It is presently doing GCC 4.3.2. If you have a machine, which already has a compiler, you are welcome to try ... mkdir /tmp/csc cd /tmp/csc wget http://www.casita.net/pub/csc/makefile make gcc.mk make gcc.src make gcc.cfg make gcc.exe sudo make gcc.ins Then to run the new compiler, set it first in command search ... PATH=/opt/gcc/bin:$PATH ; export PATH You may want to do the same for BINUTILS which is at the 2.18.50.0.6 level. (And also lands safely under /opt/gcc.) *** Using /usr/opt to build GCC *** I also often use a non-intrusive scheme for building packages, including GCC, which lets you isolate things from the operating system. (So it does not break your box out of DPKG or RPM management.) Someone at Rice University came up with the basic idea years ago, and I have come to rely on it heavily. I found the build logic for GCC 4.3.2 for this scheme and uploaded it to the web. /usr/opt by design keeps everything AWAY FROM the operating system, so here too your old compiler would still be available. (And would again still be the default.) There are more steps (than with CSCRATCH), but this is a much more open-ended solution. mkdir /tmp/gcc-4.3.2 cd /tmp/gcc-4.3.2 wget http://www.casita.net/pub/gcc/gcc-4.3.2.mak cp -p gcc-4.3.2.mak makefile wget http://www.casita.net/pub/setup.sh cp -p setup.sh setup chmod a+rx setup make source make config make sudo mkdir -m 1777 /usr/opt make install ./setup Again, to run the new compiler, make it first in your command search ... PATH=/usr/opt/gcc/bin:$PATH ; export PATH You may want to do the same with binutils-2.18.50.0.9. I do not know how well a home-grown GCC will behave w/r/t your mixed 32-bit and 64-bit environment. Personally, I would use one of the above methods and then rigorously test the stuff built by the new GCC. (Most of the libraries are outside of compiler space.) Rigorous testing is standard operating procedure, yes? :-) -- R; On Fri, Jan 8, 2010 at 11:26, rui guidevelo...@gmail.com wrote: Hi all, I am looking for gcc 4.2 onwards on sles9 x86_64. Can I get a prebuilt gcc or do i have to build it myself? if building is the way to go, what should be the configuration options? I would like GCC to have 64 bit libs - having 32 bit libs is useful, but not necessary. Regards, Raja -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists
gcc 4.x.x on SLES 9
Hi all, I am looking for gcc 4.2 onwards on sles9 x86_64. Can I get a prebuilt gcc or do i have to build it myself? if building is the way to go, what should be the configuration options? I would like GCC to have 64 bit libs - having 32 bit libs is useful, but not necessary. Regards, Raja -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: gcc 4.x.x on SLES 9
Hi Mark, Thanks for your reply. So you mean to say that i can get source rpm for later SLES, say SLES 11 and then configure, make bootstrap it using the spec file in the src rpm. Also can two versions of gcc exist on one system, if yes then how do i setup include, link and lib paths? Regards, Raja On Fri, Jan 8, 2010 at 6:06 PM, Mark Post mp...@novell.com wrote: On 1/8/2010 at 11:26 AM, rui guidevelo...@gmail.com wrote: Hi all, I am looking for gcc 4.2 onwards on sles9 x86_64. Can I get a prebuilt gcc or do i have to build it myself? Someone, somewhere, may have built it, but finding it might be impossible. if building is the way to go, what should be the configuration options? I would get the source RPM for whatever version of SLES has that version, and use what was in the spec file. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
Thanks John for a detailed explanation - I will keep these points in mind, next time I come across such problem. You are right, it really helps a lot, to be an assembly language programmer. Regards, Raja On Sat, Nov 21, 2009 at 11:13 PM, John Summerfield deb...@herakles.homelinux.org wrote: rui wrote: I am now thinking of becoming a machine level programmer :) Thanks Christian and others for your valuable feedback and helping me solve the problem. Very valuable learning, to inspect the actual instructions for me. This code was in place for Linux only, I have now gotten round it for s390. This is one of the times when having programmed in assembly language is useful:-) When trying to solve these kinds of problems, it's useful to know that the CPU is trying to digest, and what it's capable of (the reason I asked about the model). Most (I think) CPUs advance the program counter after fetching the instruction. An obvious exception is when the instruction can't be accessed (program check 4 or 5). When the CPU has suffered acute indigestion, backtracking can be a bit of guesswork. First try, depending on the particular error, is to look at the immediate prior bytes to see what might be instructions that might have given rise to the existing PC value and the error. In the case of addressing errors, it helps to understand how branches are taken. Eons ago when I learned this stuff, a program check at one of these addresses: x'48' x'50' x'4800' x'5000' generally meant a program had tried to read or write an unopened file and there was usually a message about a missing DD card. R14 contained the return address and R1 the address of the relevant DCB. _I_ generally use R12 as my base register in my assembler programs, and one time a missing DD lead to an unconditional branch on R12 at one of those addresses. The result, a S322 abend (used all CPU time) and a greater time limit lead to a S322 abend. Umm. -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
Hi, The problem is, it happens at the start of the below mentioned function TDmain::Initialise (this=0x176c4c8) at crutil2.cpp:7571 Before there was a call to srand(time(NULL)) there(the first line), i thought that was the problem, i have removed it now but it comes on the very first line of the function -- the call stack seems like corrupted, for i don't know what reason! cat /proc/cpuinfo vendor_id : IBM/S390 # processors: 1 bogomips per cpu: 348.97 processor 0: version = FF, identification = 0ECA7E, machine = 2096 --- This is what I am getting using gdb bt [New Thread 1081117632 (LWP 11301)] [New Thread 1083214784 (LWP 11302)] Program received signal SIGILL, Illegal instruction. [Switching to Thread 1079019904 (LWP 11298)] TDmain::Initialise (this=0x176c4c8) at crutil2.cpp:7571 7571 header = NULL; (gdb) bt #0 TDmain::Initialise (this=0x176c4c8) at cutil2.cpp:7571 #1 0x007ccfe4 in TDmain (this=0x176c4c8, nm=0x1163c20 Meta DLL, fcache=0x17562a0, icache=0x174db48) at crutil2.cpp:7636 - info reg r0 0x0 0 r1 0x27f639 r2 0x176c4d024560848 r3 0x0 0 r4 0x807ccfda -2139303974 r5 0x0 0 r6 0x0 0 r7 0x74a8 2147480744 r8 0x422d40 4336960 r9 0x800ae330 -2146770128 r100x40015be4 1073830884 r110x7fffa540 2147460416 r120x2000 8192 r130x807cc730 -2139306192 r140x807ccfe4 -2139303964 r150x7fffa540 2147460416 pc 0x7cc76e 0x7cc76e TDmain::Initialise()+70 cc 0x2 2 This is the output for the top instruction from call stack (gdb) print Initialise $1 = TDmain::Initialise() (gdb) x/i Initialise 0x7cc728 _ZN7TDmain10InitialiseEv: stm %r11,%r15,44(%r15) (gdb) x/i 0x007ccfe4 0x7ccfe4 TDmain+236: l %r1,104(%r11) Also what should i set in -march - should it be g5, z900 or leave it to default i.e. nothing? Thanks for all the help on this matter. Regards, Raja On Fri, Nov 20, 2009 at 6:55 AM, John Summerfield deb...@herakles.homelinux.org wrote: rui wrote: Hi all, This is my first message to this list and I am having a strange problem on s390x system. uname -a Linux suse9 2.6.5-7.97-s390x #1 SMP Fri Jul 2 14:21:59 UTC 2004 s390x s390x s390x GNU/Linux I am building my software on this system with these compiler/linker options as 32bit build. CC=g++ -m31 COPTS_LINUX_OS390=-L. -Wall -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_THREAD_SAFE -D_REENTRANT -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -D_POSIX_C_SOURCE=199506L LOPTS_LINUX_OS390=-L. -Wall -lpthread -lm -lnsl -lrt -ldl -lcrypt -L/usr/X11R6/lib The build is fine but when I execute my software and for a certain operation i receive SIGILL, which I don't seem to understand -- it happens at a start of a c++ based constructor in which the only difference from the rest of the application is that stl is used. I can't seem to get to the bottom of this, are there any compile/link flags, which I am not using correctly or is there something else. The code is built as 32bit on hp, solaris, suse linux and redhat linux without any problem and works fine, even on 64 bit version of redhat linux. Can anybody help me out with this, please? What model of CPU are you using? cat /proc/cpuinfo Can you use gdb to find just what the instruction is that it's failing on and post the hex code to the list? Just for giggles (and if you have the time), fire up Hercules on a PC and try on that. I don't think that you can actually choose the CPU it emulates (I've not used it for some time, I used to specify model=3168 and that ran Linux just fine), but it's a different processor. -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
(%r11) 0x007cc83a _ZN7TDTmain10InitialiseEv+274: l %r1,16(%r13) 0x007cc83e _ZN7TDTmain10InitialiseEv+278: basr%r14,%r1 0x007cc840 _ZN7TDTmain10InitialiseEv+280: st %r2,1504(%r12) 0x007cc844 _ZN7TDTmain10InitialiseEv+284: l %r2,96(%r11) 0x007cc848 _ZN7TDTmain10InitialiseEv+288: lhi %r3,0 0x007cc84c _ZN7TDTmain10InitialiseEv+292: l %r1,20(%r13) 0x007cc850 _ZN7TDTmain10InitialiseEv+296: basr%r14,%r1 0x007cc852 _ZN7TDTmain10InitialiseEv+298: l %r1,96(%r11) 0x007cc856 _ZN7TDTmain10InitialiseEv+302: lhi %r3,0 0x007cc85a _ZN7TDTmain10InitialiseEv+306: st %r3,1484(%r1) 0x007cc85e _ZN7TDTmain10InitialiseEv+310: l %r1,24(%r13) 0x007cc862 _ZN7TDTmain10InitialiseEv+314: l %r3,96(%r11) 0x007cc866 _ZN7TDTmain10InitialiseEv+318: ahi %r3,276 0x007cc86a _ZN7TDTmain10InitialiseEv+322: lr %r2,%r1 0x007cc86c _ZN7TDTmain10InitialiseEv+324: lhi %r4,254 0x007cc870 _ZN7TDTmain10InitialiseEv+328: l %r1,28(%r13) 0x007cc874 _ZN7TDTmain10InitialiseEv+332: basr%r14,%r1 0x007cc876 _ZN7TDTmain10InitialiseEv+334: l %r4,168(%r11) 0x007cc87a _ZN7TDTmain10InitialiseEv+338: lm %r11,%r15,156(%r11) 0x007cc87e _ZN7TDTmain10InitialiseEv+342: br %r4 End of assembler dump. echo 1 /proc/sys/kernel/userprocess_debug is also done and here is when SIGILL happens, i think st: Version 20040318, fixed bufsize 32768, s/g segs 256 crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=1, erc=4, rsid=9 User process fault: interruption code 0x40006 CPU:0Not tainted Process crcat (pid: 12533, task: 00780878, ksp: 1140f4f0) User PSW : 0705e0008000 007cc76e (0x7cc76e) User GPRS: 0200027f 0176c4c8 807ccfda 74a8 00422d40 800ae330 40015be4 7fffa540 02002000 0200807cc730 807ccfe4 7fffa540 User Code: 58 10 b0 60 a7 28 00 00 50 20 15 d0 58 10 b0 60 a7 38 00 00 Regards, Raja On Fri, Nov 20, 2009 at 12:03 PM, Christian Borntraeger borntrae...@de.ibm.com wrote: Am Freitag 20 November 2009 11:53:44 schrieb rui: Hi, The problem is, it happens at the start of the below mentioned function TDmain::Initialise (this=0x176c4c8) at crutil2.cpp:7571 Before there was a call to srand(time(NULL)) there(the first line), i thought that was the problem, i have removed it now but it comes on the very first line of the function -- the call stack seems like corrupted, for i don't know what reason! cat /proc/cpuinfo vendor_id : IBM/S390 # processors: 1 bogomips per cpu: 348.97 processor 0: version = FF, identification = 0ECA7E, machine = 2096 2096 indicates a z9 [...] pc 0x7cc76e 0x7cc76e TDmain::Initialise()+70 The instruction before this address is certainly interesting. (gdb) print Initialise $1 = TDmain::Initialise() (gdb) x/i Initialise 0x7cc728 _ZN7TDmain10InitialiseEv: stm %r11,%r15,44(%r15) Can you show the full disassembly of Initialize (use the disassemble command)? A SIGILL can come for several reasons: - opcode of newer machines (unlikely on a z9) - specification exception - data exception and more. In addition to the disassemble output, you can also do (as root) echo 1 /proc/sys/kernel/userprocess_debug This will print some info in dmesg for exceptions in userspace. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
Hi Christian, Yes, there is floating point precision related stuff, in the code on the very first line. unsigned int cm = 0x27f; _FPU_SETCW(cm); This is done for all linux systems for achieving 64 bit floating point precision. So, do I need to ifdef it out for s390 or is there an alternative for it on s390x system? BTW, how did you match the spfc to user process fault, can you let me know about it, please? Thanks very much. Regards, Raja On Fri, Nov 20, 2009 at 1:28 PM, Christian Borntraeger borntrae...@de.ibm.com wrote: 0x007cc758 _ZN7TDTmain10InitialiseEv+48: lr %r11,%r15 0x007cc75a _ZN7TDTmain10InitialiseEv+50: st %r2,96(%r11) 0x007cc75e _ZN7TDTmain10InitialiseEv+54: lhi %r1,639 0x007cc762 _ZN7TDTmain10InitialiseEv+58: st %r1,100(%r11) 0x007cc766 _ZN7TDTmain10InitialiseEv+62: l %r1,100(%r11) 0x007cc76a _ZN7TDTmain10InitialiseEv+66: sfpc%r1,%r0 [...] User process fault: interruption code 0x40006 CPU:0Not tainted Process crcat (pid: 12533, task: 00780878, ksp: 1140f4f0) User PSW : 0705e0008000 007cc76e (0x7cc76e) User GPRS: 0200027f 0176c4c8 807ccfda 74a8 00422d40 800ae330 40015be4 7fffa540 02002000 0200807cc730 807ccfe4 7fffa540 User Code: 58 10 b0 60 a7 28 00 00 50 20 15 d0 58 10 b0 60 a7 38 00 00 Ok, so we have a specification exception for the sfpc instruction. Are there some floating point instruction in this function? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
I am now thinking of becoming a machine level programmer :) Thanks Christian and others for your valuable feedback and helping me solve the problem. Very valuable learning, to inspect the actual instructions for me. This code was in place for Linux only, I have now gotten round it for s390. Regards, Raja On Fri, Nov 20, 2009 at 3:17 PM, Christian Borntraeger borntrae...@de.ibm.com wrote: Am Freitag 20 November 2009 15:54:07 schrieb rui: Hi Christian, Yes, there is floating point precision related stuff, in the code on the very first line. unsigned int cm = 0x27f; _FPU_SETCW(cm); Ok. That does the sfpc. This is done for all linux systems for achieving 64 bit floating point precision. So, do I need to ifdef it out for s390 or is there an alternative for it on s390x system? So here is my understanding: I strongly believe the mask for _FPU_SETCW is platform specific, the code should use appropriate macros for floating point control. Your 0x27f is based on the Intel numbers and will probably also have a different effect on sparc, power, arm and mips (it might not fault, but could give you strange results) There are no precision bits for s390 in the floating point control. On s390 the precision depends on the instruction, and gcc should use double precion instruction for variables declared as double. BTW, how did you match the spfc to user process fault, can you let me know about it, please? User process fault: interruption code 0x40006 ^^ The 6 indicates an specification exception. I got the sfpc from the pc value in gdb + the disassembly: pc 0x7cc76e 0x7cc76e TDmain::Initialise()+70 [...] 0x007cc762 _ZN7TDTmain10InitialiseEv+58: st %r1,100(%r11) 0x007cc766 _ZN7TDTmain10InitialiseEv+62: l %r1,100(%r11) 0x007cc76a _ZN7TDTmain10InitialiseEv+66: sfpc%r1,%r0 0x007cc76e _ZN7TDTmain10InitialiseEv+70: l %r1,96(%r11) 0x007cc772 _ZN7TDTmain10InitialiseEv+74: lhi %r2,0 On a fault, the pc usually points to the following instruction (or in rare cases to the faulting instruction) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
SIGILL problem on s390x
Hi all, This is my first message to this list and I am having a strange problem on s390x system. uname -a Linux suse9 2.6.5-7.97-s390x #1 SMP Fri Jul 2 14:21:59 UTC 2004 s390x s390x s390x GNU/Linux I am building my software on this system with these compiler/linker options as 32bit build. CC=g++ -m31 COPTS_LINUX_OS390=-L. -Wall -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_THREAD_SAFE -D_REENTRANT -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -D_POSIX_C_SOURCE=199506L LOPTS_LINUX_OS390=-L. -Wall -lpthread -lm -lnsl -lrt -ldl -lcrypt -L/usr/X11R6/lib The build is fine but when I execute my software and for a certain operation i receive SIGILL, which I don't seem to understand -- it happens at a start of a c++ based constructor in which the only difference from the rest of the application is that stl is used. I can't seem to get to the bottom of this, are there any compile/link flags, which I am not using correctly or is there something else. The code is built as 32bit on hp, solaris, suse linux and redhat linux without any problem and works fine, even on 64 bit version of redhat linux. Can anybody help me out with this, please? Regards, Raja -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
Hi Mark, Thanks for the input, I just checked the options available for g++ in http://gcc.gnu.org/onlinedocs/gcc/S_002f390-and-zSeries-Options.html What option should i use, I think by default it would be using g5 as it 32 bit, can you please confirm? -march=cpu-typeGenerate code that will run on cpu-type, which is the name of a system representing a certain processor type. Possible values for cpu-type are `g5', `g6', `z900', `z990', `z9-109', `z9-ec' and `z10'. When generating code using the instructions available on z/Architecture, the default is -march=z900. Otherwise, the default is -march=g5. Regards, Raja On Thu, Nov 19, 2009 at 6:11 PM, Mark Post mp...@novell.com wrote: On 11/19/2009 at 12:54 PM, rui guidevelo...@gmail.com wrote: -snip- Can anybody help me out with this, please? This is just a wild guess on my part, but it sounds as though the compiler is generating instructions for a newer hardware generation than what you're running on. So, you might want to add a march= parameter to your compile and see if that helps. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SIGILL problem on s390x
Hi Neale, I am using -m31 already. CC=g++ -m31 Regards, Raja On Thu, Nov 19, 2009 at 6:26 PM, Neale Ferguson ne...@sinenomine.netwrote: Just use -m31 on the gcc command line. On 11/19/09 1:23 PM, rui guidevelo...@gmail.com wrote: Hi Mark, Thanks for the input, I just checked the options available for g++ in http://gcc.gnu.org/onlinedocs/gcc/S_002f390-and-zSeries-Options.html What option should i use, I think by default it would be using g5 as it 32 bit, can you please confirm? -march=cpu-typeGenerate code that will run on cpu-type, which is the name of a system representing a certain processor type. Possible values for cpu-type are `g5', `g6', `z900', `z990', `z9-109', `z9-ec' and `z10'. When generating code using the instructions available on z/Architecture, the default is -march=z900. Otherwise, the default is -march=g5. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
