Обсуждение: Patches for Pgsql on Linux/Alpha (RE: Last Call...)
Ok, here they are, the long awaited patches to make pgsql compile once again on Linux/Alpha. It turned out that our old friend S_LOCK was the problem. Apparently some one had pulled the S_LOCK assembly code out of the static function that I put it in, and attempted to make it inlined again (which is what broke it the first time around). On a whim, I searched the net looking for an Alpha Assembly Programmer's Manual, and see if it would help me any. I was lucky on both accounts. I found the manual, and quickly figured out to make local labels. So... The S_LOCK code for Linux/Alpha is finally safe for inlining! :)Here is the patch for ./pgsql/src/include/storage/s_lock.h 89c87 < bne $0, already_set \n\ --- > bne $0, 3f \n\ 91c89 < bne $0, already_set \n\ --- > bne $0, 3f \n\ 94,95c92,93 < beq $0, stqc_fail \n\ < success: bis $31, $31, %1 \n\ --- > beq $0, 2f \n\ > bis $31, $31, %1 \n\ 97,100c95,98 < jmp $31, end \n\ < stqc_fail: or $31, 1, $0 \n\ < already_set: bis $0, $0, %1 \n\ < end: nop ": "=m"(*lock), "=r"(_res): :"0"); --- > jmp $31, 4f \n\ > 2: or $31, 1, $0 \n\ > 3: bis $0, $0, %1 \n\ > 4: nop ": "=m"(*lock), "=r"(_res): :"0"); Though there are two other catches at the moment in compiling pgsql on Alpha as well: 1. The optimization flag, -O2, that is used, causes some code to fail to compile with very strange errors, and it causes s_locks to jam. Apparently this is due to the (somewhat) unstable nature of gcc/egcs on Alphas at the moment. Turning it down to -O1 solves the problem and everything works fine. 2. C++ is pretty much broken on Linux/Alpha (Debian 2.0 at least), due to missing header files. This means that libpq++ can't be compiled. Either tell configure not to detect/use C++, or comment out the line in interfaces/Makefile that causes libpq++ to be built. Beyond that, it should compile, install, and initdb just fine. Regressions tests are a mixed bag at this time (see my seperate message concerning this), but look promising.Here is the specs on my machine for reference: XL366 Alpha w/192MB of RAM Debian 2.0 Alpha (unstable) Linux 2.0.34 gcc 2.91.57-5 glibc 2.0.7t-1 I would be very interested in regression tests/results from people running RedHat on thier Alphas. Would help me to narrow down what is causing some of the regression test problems. If you do send them to me, make sure to include what kernel, gcc, and glibc you are using. Thanks. Ok, that should pretty much cover it for the 6.4 release on the Linux/Alpha end. I would mark it as working, but still in need of further work. TTYAL. ---------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | ---------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu | ---------------------------------------------------------------------------- | http://www-ugrad.cs.colorado.edu/~rkirkpat/ | ----------------------------------------------------------------------------
> > Ok, here they are, the long awaited patches to make pgsql compile > once again on Linux/Alpha. It turned out that our old friend S_LOCK was > the problem. Apparently some one had pulled the S_LOCK assembly code out > of the static function that I put it in, and attempted to make it inlined > again (which is what broke it the first time around). On a whim, I > searched the net looking for an Alpha Assembly Programmer's Manual, and > see if it would help me any. I was lucky on both accounts. I found the > manual, and quickly figured out to make local labels. So... The S_LOCK > code for Linux/Alpha is finally safe for inlining! :) > Here is the patch for ./pgsql/src/include/storage/s_lock.h > > 89c87 > < bne $0, already_set \n\ > --- > > bne $0, 3f \n\ > 91c89 > < bne $0, already_set \n\ > --- > > bne $0, 3f \n\ > 94,95c92,93 > < beq $0, stqc_fail \n\ > < success: bis $31, $31, %1 \n\ > --- > > beq $0, 2f \n\ > > bis $31, $31, %1 \n\ > 97,100c95,98 > < jmp $31, end \n\ > < stqc_fail: or $31, 1, $0 \n\ > < already_set: bis $0, $0, %1 \n\ > < end: nop ": "=m"(*lock), "=r"(_res): :"0"); > --- > > jmp $31, 4f \n\ > > 2: or $31, 1, $0 \n\ > > 3: bis $0, $0, %1 \n\ > > 4: nop ": "=m"(*lock), "=r"(_res): :"0"); > > Though there are two other catches at the moment in compiling > pgsql on Alpha as well: > I have applied this. However, we normally prefer context diffs. Fortunately, this patch had old and new rows, so it was almost the same as a context diff. It also only dealt with the alpha locking code, which he stated was clearly broken, so application seemed good. Some of your more agressive patches may have to wait a week until 6.4 is released. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, 30 Oct 1998, Bruce Momjian wrote: > I have applied this. However, we normally prefer context diffs. > Fortunately, this patch had old and new rows, so it was almost the same > as a context diff. Sorry... I was in a bit of a hurry to get it out, and just grabbed the a patch I had made a while back. It was so small and only covered one file, I didn't think there would be much problem. > It also only dealt with the alpha locking code, which he stated was > clearly broken, so application seemed good. Some of your more agressive > patches may have to wait a week until 6.4 is released. By more aggressive patches, do you mean the optimizer and libpq++ advice, or did I miss something? Also, by 'he' and 'you' who do you mean? I think you were speaking to more than one person, but I am not sure... Please clarify, thanks. :) ---------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | ---------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu | ---------------------------------------------------------------------------- | http://www-ugrad.cs.colorado.edu/~rkirkpat/ | ----------------------------------------------------------------------------
> On Fri, 30 Oct 1998, Bruce Momjian wrote: > > > I have applied this. However, we normally prefer context diffs. > > Fortunately, this patch had old and new rows, so it was almost the same > > as a context diff. > > Sorry... I was in a bit of a hurry to get it out, and just grabbed > the a patch I had made a while back. It was so small and only covered one > file, I didn't think there would be much problem. Yes, I am just a little paranoid this close to final release, November 1. > > > It also only dealt with the alpha locking code, which he stated was > > clearly broken, so application seemed good. Some of your more agressive > > patches may have to wait a week until 6.4 is released. > > By more aggressive patches, do you mean the optimizer and libpq++ > advice, or did I miss something? Also, by 'he' and 'you' who do you mean? > I think you were speaking to more than one person, but I am not sure... > Please clarify, thanks. :) 'he' and 'your' is you. By more agressive, I mean things that could affect other platforms, were we can't get 100% agreement from the other developers that this is a safe change. Let's see what you find, and what other say. I don't want to apply something at this point that is going to potentailly break another platform, and the date/time routines have historically done this. We can put them in a 6.4.* minor release, which I am sure we will have a few weeks after the major. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, 30 Oct 1998, Bruce Momjian wrote: > Yes, I am just a little paranoid this close to final release, November > 1. Understandable. Next time they will be in a much cleaner format. > > By more aggressive patches, do you mean the optimizer and libpq++ > > advice, or did I miss something? Also, by 'he' and 'you' who do you mean? > > I think you were speaking to more than one person, but I am not sure... > > Please clarify, thanks. :) > > 'he' and 'your' is you. By more agressive, I mean things that could > affect other platforms, were we can't get 100% agreement from the other > developers that this is a safe change. > > Let's see what you find, and what other say. I don't want to apply > something at this point that is going to potentailly break another > platform, and the date/time routines have historically done this. > > We can put them in a 6.4.* minor release, which I am sure we will have a > few weeks after the major. Ok, I follow now, thanks for the clarification. The patch to the Alpha S_LOCK code is the only patch I have at this time. I guess I should have been clearer about the datetime problems. I do not have even a prospective patch for those problems at this time, or plan to have the time to even begin such a patch for at least a week or two. When I do get such a patch, I will make sure to have a few other Linux/Alpha people test it, as well as test what it does to a Linux/Intel compile of pgsql before I post it to be added to the CVS tree. The alpha S_LOCK patch only affected a single OS, and thought it would be rather safe. Next time I will try and get it in earlier (last week or two has been hectic with school :( ). Thanks for your understanding. TTYL. ---------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | ---------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu | ---------------------------------------------------------------------------- | http://www-ugrad.cs.colorado.edu/~rkirkpat/ | ----------------------------------------------------------------------------