|
»
»
PLT problem on Sparc
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
PLT problem on Sparc
by Jerry James-3
::
Rate this Message:
A group of people are trying to get a Sparc build of Fedora put
together. I just received a report from them that attempting to build GCL failed. The immediate problem is that plt.h is being generated with these contents: MY_PLT(), MY_PLT(), MY_PLT(_mcount), MY_PLT(_setjmp), MY_PLT(acos), MY_PLT(acosh), MY_PLT(asin), MY_PLT(asinh), MY_PLT(atan), MY_PLT(atanh), MY_PLT(cos), MY_PLT(cosh), MY_PLT(exp), MY_PLT(fdopen), MY_PLT(feof), MY_PLT(log), MY_PLT(memset), MY_PLT(read), MY_PLT(sin), MY_PLT(sincos), MY_PLT(sinh), MY_PLT(sqrt), MY_PLT(sscanf), MY_PLT(tan), MY_PLT(tanh), MY_PLT(write) Those two empty invocations of MY_PLT() at the top are causing a compilation error. It's been a long time since I last used AWK. Before I go dig out my AWK manual to try to figure out what happened here, does anybody have any ideas on what could lead to those empty entries? Thanks, -- Jerry James http://www.jamezone.org/ _______________________________________________ Gcl-devel mailing list Gcl-devel@... http://lists.gnu.org/mailman/listinfo/gcl-devel |
|
|
Re: PLT problem on Sparc
by Camm Maguire-2
::
Rate this Message:
Greetings! Could you please post the results of
nm o/plttest.o and the result of configure's test for leading underscores in object symbols? Apparently, nm is giving output akin to " U _ " or some such. Take care, Jerry James <loganjerry@...> writes: > A group of people are trying to get a Sparc build of Fedora put > together. I just received a report from them that attempting to build > GCL failed. The immediate problem is that plt.h is being generated > with these contents: > > MY_PLT(), > MY_PLT(), > MY_PLT(_mcount), > MY_PLT(_setjmp), > MY_PLT(acos), > MY_PLT(acosh), > MY_PLT(asin), > MY_PLT(asinh), > MY_PLT(atan), > MY_PLT(atanh), > MY_PLT(cos), > MY_PLT(cosh), > MY_PLT(exp), > MY_PLT(fdopen), > MY_PLT(feof), > MY_PLT(log), > MY_PLT(memset), > MY_PLT(read), > MY_PLT(sin), > MY_PLT(sincos), > MY_PLT(sinh), > MY_PLT(sqrt), > MY_PLT(sscanf), > MY_PLT(tan), > MY_PLT(tanh), > MY_PLT(write) > > Those two empty invocations of MY_PLT() at the top are causing a > compilation error. It's been a long time since I last used AWK. > Before I go dig out my AWK manual to try to figure out what happened > here, does anybody have any ideas on what could lead to those empty > entries? > > Thanks, > -- > Jerry James > http://www.jamezone.org/ > > > _______________________________________________ > Gcl-devel mailing list > Gcl-devel@... > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > > -- Camm Maguire camm@... ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@... http://lists.gnu.org/mailman/listinfo/gcl-devel |
|
|
Re: PLT problem on Sparc
by Jerry James-3
::
Rate this Message:
On Fri, Jun 19, 2009 at 11:10 AM, Camm Maguire<camm@...> wrote:
> Greetings! Could you please post the results of > > nm o/plttest.o > > and the result of configure's test for leading underscores in object > symbols? > > Apparently, nm is giving output akin to " U _ " or some such. > > Take care, Thanks to Dennis Gilmore, I already have part of the information you requested. Here is the output of nm: [mockbuild@daedalus gcl-2.6.8]$ nm o/plttest.o U U U _IO_getc U _IO_putc U __isoc99_sscanf U _mcount U _setjmp U acos U acosh U asin U asinh U atan U atanh U cos U cosh U exp U fdopen U feof U log 0000000000000000 T main U memset U read U sin U sincos U sinh U sqrt U tan U tanh U write When I saw that, I wondered how there could be 2 symbols with no names. So I asked Dennis to try objdump and readelf as well. Here is the output from those two tools: [mockbuild@daedalus gcl-2.6.8]$ objdump -t o/plttest.o o/plttest.o: file format elf64-sparc SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 plttest.c 0000000000000000 l d .text 0000000000000000 .text 0000000000000000 l d .data 0000000000000000 .data 0000000000000000 l d .bss 0000000000000000 .bss 0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev 0000000000000000 l d .debug_info 0000000000000000 .debug_info 0000000000000000 l d .debug_line 0000000000000000 .debug_line 0000000000000000 l d .rodata.str1.8 0000000000000000 .rodata.str1.8 0000000000000000 l d .debug_loc 0000000000000000 .debug_loc 0000000000000000 l d .debug_pubnames 0000000000000000 .debug_pubnames 0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges 0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges 0000000000000000 l d .debug_str 0000000000000000 .debug_str 0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU- stack 0000000000000000 l d .eh_frame 0000000000000000 .eh_frame 0000000000000000 l d .comment 0000000000000000 .comment 0000000000000000 g F .text 0000000000000264 main REG_G2 g R *UND* 0000000000000000 #scratch REG_G3 g R *UND* 0000000000000000 #scratch 0000000000000000 *UND* 0000000000000000 __isoc99_sscanf 0000000000000000 *UND* 0000000000000000 memset 0000000000000000 *UND* 0000000000000000 _IO_getc 0000000000000000 *UND* 0000000000000000 _IO_putc 0000000000000000 *UND* 0000000000000000 feof 0000000000000000 *UND* 0000000000000000 fdopen 0000000000000000 *UND* 0000000000000000 read 0000000000000000 *UND* 0000000000000000 write 0000000000000000 *UND* 0000000000000000 _mcount 0000000000000000 *UND* 0000000000000000 _setjmp 0000000000000000 *UND* 0000000000000000 cos 0000000000000000 *UND* 0000000000000000 sin 0000000000000000 *UND* 0000000000000000 sincos 0000000000000000 *UND* 0000000000000000 tan 0000000000000000 *UND* 0000000000000000 acos 0000000000000000 *UND* 0000000000000000 asin 0000000000000000 *UND* 0000000000000000 atan 0000000000000000 *UND* 0000000000000000 cosh 0000000000000000 *UND* 0000000000000000 sinh 0000000000000000 *UND* 0000000000000000 tanh 0000000000000000 *UND* 0000000000000000 acosh 0000000000000000 *UND* 0000000000000000 asinh 0000000000000000 *UND* 0000000000000000 atanh 0000000000000000 *UND* 0000000000000000 exp 0000000000000000 *UND* 0000000000000000 log 0000000000000000 *UND* 0000000000000000 sqrt [mockbuild@daedalus gcl-2.6.8]$ readelf -s o/plttest.o Symbol table '.symtab' contains 46 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS plttest.c 2: 0000000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 SECTION LOCAL DEFAULT 3 4: 0000000000000000 0 SECTION LOCAL DEFAULT 4 5: 0000000000000000 0 SECTION LOCAL DEFAULT 5 6: 0000000000000000 0 SECTION LOCAL DEFAULT 6 7: 0000000000000000 0 SECTION LOCAL DEFAULT 8 8: 0000000000000000 0 SECTION LOCAL DEFAULT 10 9: 0000000000000000 0 SECTION LOCAL DEFAULT 11 10: 0000000000000000 0 SECTION LOCAL DEFAULT 12 11: 0000000000000000 0 SECTION LOCAL DEFAULT 14 12: 0000000000000000 0 SECTION LOCAL DEFAULT 16 13: 0000000000000000 0 SECTION LOCAL DEFAULT 17 14: 0000000000000000 0 SECTION LOCAL DEFAULT 19 15: 0000000000000000 0 SECTION LOCAL DEFAULT 20 16: 0000000000000000 0 SECTION LOCAL DEFAULT 18 17: 0000000000000000 612 FUNC GLOBAL DEFAULT 1 main 18: 0000000000000002 0 REGISTER GLOBAL DEFAULT UND 19: 0000000000000003 0 REGISTER GLOBAL DEFAULT UND 20: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __isoc99_sscanf 21: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND memset 22: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _IO_getc 23: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _IO_putc 24: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND feof 25: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND fdopen 26: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND read 27: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND write 28: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _mcount 29: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _setjmp 30: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND cos 31: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sin 32: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sincos 33: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND tan 34: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND acos 35: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND asin 36: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND atan 37: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND cosh 38: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sinh 39: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND tanh 40: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND acosh 41: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND asinh 42: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND atanh 43: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND exp 44: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND log 45: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sqrt So it looks like the culprits are the two REGISTER entries for REG_G2 and REG_G3. -- Jerry James http://www.jamezone.org/ _______________________________________________ Gcl-devel mailing list Gcl-devel@... http://lists.gnu.org/mailman/listinfo/gcl-devel |
|
|
Re: PLT problem on Sparc
by Camm Maguire-2
::
Rate this Message:
Greetings! Does this patch just committed into 2.6.8pre fix this
problem? Index: makefile =================================================================== RCS file: /sources/gcl/gcl/o/makefile,v retrieving revision 1.27.6.9.2.1.6.1.6.6 diff -u -r1.27.6.9.2.1.6.1.6.6 makefile --- makefile 18 Oct 2006 17:08:56 -0000 1.27.6.9.2.1.6.1.6.6 +++ makefile 19 Jun 2009 19:22:32 -0000 @@ -150,7 +150,7 @@ $(CC) -c $(CFLAGS) $(DEFS) $*.c $(AUX_INFO) plt.h: plttest.o - nm $< | $(AWK) '/ U / {a=$$2;if (k) sub("^_","",a);\ + nm $< | $(AWK) '/ U / {if ($$NF!=2) next;a=$$2;if (k) sub("^_","",a);\ print a}' \ k=$(LEADING_UNDERSCORE) |\ sort | \ Take care, and thanks as always for your very helpful feedback! Jerry James <loganjerry@...> writes: > A group of people are trying to get a Sparc build of Fedora put > together. I just received a report from them that attempting to build > GCL failed. The immediate problem is that plt.h is being generated > with these contents: > > MY_PLT(), > MY_PLT(), > MY_PLT(_mcount), > MY_PLT(_setjmp), > MY_PLT(acos), > MY_PLT(acosh), > MY_PLT(asin), > MY_PLT(asinh), > MY_PLT(atan), > MY_PLT(atanh), > MY_PLT(cos), > MY_PLT(cosh), > MY_PLT(exp), > MY_PLT(fdopen), > MY_PLT(feof), > MY_PLT(log), > MY_PLT(memset), > MY_PLT(read), > MY_PLT(sin), > MY_PLT(sincos), > MY_PLT(sinh), > MY_PLT(sqrt), > MY_PLT(sscanf), > MY_PLT(tan), > MY_PLT(tanh), > MY_PLT(write) > > Those two empty invocations of MY_PLT() at the top are causing a > compilation error. It's been a long time since I last used AWK. > Before I go dig out my AWK manual to try to figure out what happened > here, does anybody have any ideas on what could lead to those empty > entries? > > Thanks, > -- > Jerry James > http://www.jamezone.org/ > > > _______________________________________________ > Gcl-devel mailing list > Gcl-devel@... > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > > -- Camm Maguire camm@... ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@... http://lists.gnu.org/mailman/listinfo/gcl-devel |
|
|
Re: PLT problem on Sparc
by Jerry James-3
::
Rate this Message:
On Fri, Jun 19, 2009 at 1:24 PM, Camm Maguire<camm@...> wrote:
> Greetings! Does this patch just committed into 2.6.8pre fix this > problem? Thanks, Camm. You've saved me from having to re-learn AWK! :-) I'll get back with the people who have the Sparc hardware and have them give this a try. I'm going to be out of touch for a couple of days starting in about half an hour, though, so I probably won't make any progress on this until next week. Regards, -- Jerry James http://www.jamezone.org/ _______________________________________________ Gcl-devel mailing list Gcl-devel@... http://lists.gnu.org/mailman/listinfo/gcl-devel |
|
|
Performance
by Camm Maguire-2
::
Rate this Message:
Greetings! I'm in the middle of a major modification to the cvs head
tree, and am reviewing the performance implications. Non-vanilla function calls are about to get much faster. But there are many questions remaining. I'm doing a quick comparison of the standard benchmark results vs. sbcl. We win on quite a few, but there remain some long standing clunker areas. 1) catch/throw. (e.g. the ctak benchmark) GCL handles this via setjmp and longjmp. Right now there are way too many function calls in the implementation, but in my tree, using the new dladdress external function pointer mechanism, I can get this down to one a piece for throw and catch. This appears commensurate with the sbcl disassembly. We remain significantly slower even with these changes. A big piece is likely that we return the values on the lisp stack instead of the C stack. It would be possible to make use of setjmp's int return on 32bit machines only to return the primary value. Is there no analog on 64bit? Are there any other secrets to the sbcl implementation which might carry over to C? For this one benchmark, it is possible for the compiler to optimize away the catch/throw and simply emulate with a return (see below). I don't think this is what sbcl is doing. (defun ctak (x y z) (catch 'ctak (ctak-aux x y z))) (defun ctak-aux (x y z) (declare (fixnum x y z)) (cond ((not (< y x)) (throw 'ctak z)) (t (ctak-aux (catch 'ctak (ctak-aux (the fixnum (1- x)) y z)) (catch 'ctak (ctak-aux (the fixnum (1- y)) z x)) (catch 'ctak (ctak-aux (the fixnum (1- z)) x y)))))) 2) list cache prefetching -- sbcl does not show any explicit prefetch instructions in its disassembly of #'length, yet contiguous lists are accessed much faster than randomly located lists, whereas our performance is even with the random performance in both cases. I tried putting in explicit prefetch calls some time ago without much benefit -- this is awfully fiddly stuff which varies significantly with machine. I suspect this is due to non-optimal data compression in the GC algorithm. ... Just ran a test where sorting the list by cons address is very fast without prefetch confirming this hunch. Does anyone know of a good succinct exposition of copying and or compressing gc algorithms? Some time ago we discussed a 'shrink-wrap' gc idea for gcl -- right now our memory pages are grow only. Take care, -- Camm Maguire camm@... ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@... http://lists.gnu.org/mailman/listinfo/gcl-devel |
| Free embeddable forum powered by Nabble | Forum Help |
