* Re: 64-bit sparc instructions
@ 2001-05-24 2:24 nce
2001-05-24 4:49 ` Clint Adams
0 siblings, 1 reply; 6+ messages in thread
From: nce @ 2001-05-24 2:24 UTC (permalink / raw)
To: Clint Adams; +Cc: zsh-workers
Clint Adams wrote:
> Incidentally, I have the same problems with --disable-lfs.
>
> I'd be more inclined to blame this on the compiler, but trying
> 64-bit compilation on an UltraSPARC III running Debian and
> gcc version 3.0 20010426 (Debian prerelease), and statically-linking:
I'd been thinking the cause of the trouble was equally probable between
the compiler and the 64-bit libraries, but it seems you've eliminated
both. Does echo =(echo foo) crash the gcc executable as well?
--
Paul Ackersviller
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 64-bit sparc instructions
2001-05-24 2:24 64-bit sparc instructions nce
@ 2001-05-24 4:49 ` Clint Adams
0 siblings, 0 replies; 6+ messages in thread
From: Clint Adams @ 2001-05-24 4:49 UTC (permalink / raw)
To: nce; +Cc: zsh-workers
> I'd been thinking the cause of the trouble was equally probable between
> the compiler and the 64-bit libraries, but it seems you've eliminated
> both. Does echo =(echo foo) crash the gcc executable as well?
% Src/zsh -f
% echo =(echo foo)
/tmp/zshYdd7uR
% exit
% file Src/zsh
Src/zsh: ELF 64-bit MSB executable, SPARC V9, version 1, statically linked, not stripped
The above machine is a Sun Blade 1000 running Debian. The binary was
compiled with the prerelease gcc.
% Src/zsh -f
zsh: failed to load module: zsh/zle
% echo =(echo foo)
zsh: segmentation fault (core dumped) Src/zsh -f
% file Src/zsh
Src/zsh: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC1 Extensions Required, dynamically linked, stripped
The above machine is an Ultra 80 running Solaris 8. The binary was
compiled with Forte C. I'll see about getting the same version of gcc on
that box to provide a better comparison.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vi editting troubles
@ 2001-05-23 3:04 Paul Ackersviller
2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Paul Ackersviller @ 2001-05-23 3:04 UTC (permalink / raw)
To: Peter Stephenson, Bart Schaefer; +Cc: zsh-workers
Bart Schaefer wrote:
> > } > Does a command such as `echo =(echo foo)' work? That should use the same
> > } > temp file mechanism as fc.
> > }
> > } % echo =(echo foo)
> > } Segmentation fault (core dumped)
> >
> > Looks like you've got some sort of serious memory allocation problem
> > going on -- probably some kind of word-alignment issue -- with the heap
> > allocation code. You're going to have to give us details of your OS and
> > build environment. Did you configure with --enable-zsh-mem?
No, I didn't configure with --enable-zsh-mem, but it turns out not to make a
difference. What does make a difference is simply generating default 32-bit
sparc instructions. I'd negelected to mention that I was using Sun's
compiler and 64-bit code. I suppose it's fair to blame this one on Sun.
Peter Stephenson wrote:
> > Another strange thing I notice when I turn on shell tracing is that my
> > TRAPZERR function runs in the middle of _history_complete_word -- is
> > there something I should be doing to avoid this?
>
> Oh, yuk. We really need some way of getting the effect of `setopt
> localtraps; unfunction TRAPZERR' in all completion functions. I suppose
> that means adding it everywhere we already have `setopt localoptions'
> or `emulate -L zsh' (the latter already sets localtraps). If anybody sees
> this as their mission in life...
Are you saying this is still a potential problem in a general sense?
If it helps to know, _history_complete_word no longer shows me any
errors and this behaviour goes away with Bart's suggestion of moving
`bindkey -v' after `compinit'. You could document this as a bug, but
how can you ensure people always use this ordering?
--
Paul Ackersviller
^ permalink raw reply [flat|nested] 6+ messages in thread
* 64-bit sparc instructions
2001-05-23 3:04 vi editting troubles Paul Ackersviller
@ 2001-05-23 4:41 ` Bart Schaefer
2001-05-23 9:38 ` Andrej Borsenkow
2001-05-23 12:29 ` Clint Adams
0 siblings, 2 replies; 6+ messages in thread
From: Bart Schaefer @ 2001-05-23 4:41 UTC (permalink / raw)
To: Paul Ackersviller; +Cc: zsh-workers
On May 22, 8:04pm, Paul Ackersviller wrote:
}
} [...] What does make a difference is simply generating default 32-bit
} sparc instructions. I'd negelected to mention that I was using Sun's
} compiler and 64-bit code. I suppose it's fair to blame this one on Sun.
Is that problem solved by the following?
On May 22, 2:32pm, Clint Adams wrote:
} Subject: Re: 4.0.1-pre-5 (solaris issues)
}
} > the 64-bit Forte compiler. Can you figure out what we need to be passing
} > as a compiler argument that we aren't, or whatever?
}
} LFS64_CFLAGS: -D_LARGEFILE64_SOURCE
} LFS_CFLAGS: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
}
} By replacing the latter with the former, the test [succeeds].
If so, can you identify a configure test we can use to decide when to
use LFS64_CFLAGS instead of LFS_CFLAGS ? (The existing test is in the
definition of zsh_LARGE_FILE_SUPPORT in aczsh.m4.)
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 64-bit sparc instructions
2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer
@ 2001-05-23 9:38 ` Andrej Borsenkow
2001-05-23 16:42 ` Clint Adams
2001-05-23 12:29 ` Clint Adams
1 sibling, 1 reply; 6+ messages in thread
From: Andrej Borsenkow @ 2001-05-23 9:38 UTC (permalink / raw)
To: zsh-workers; +Cc: Paul Ackersviller
On Wed, 23 May 2001, Bart Schaefer wrote:
> On May 22, 8:04pm, Paul Ackersviller wrote:
> }
> } [...] What does make a difference is simply generating default 32-bit
> } sparc instructions. I'd negelected to mention that I was using Sun's
> } compiler and 64-bit code. I suppose it's fair to blame this one on Sun.
>
> Is that problem solved by the following?
>
> On May 22, 2:32pm, Clint Adams wrote:
> } Subject: Re: 4.0.1-pre-5 (solaris issues)
> }
> } > the 64-bit Forte compiler. Can you figure out what we need to be passing
> } > as a compiler argument that we aren't, or whatever?
> }
> } LFS64_CFLAGS: -D_LARGEFILE64_SOURCE
> } LFS_CFLAGS: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> }
> } By replacing the latter with the former, the test [succeeds].
>
> If so, can you identify a configure test we can use to decide when to
> use LFS64_CFLAGS instead of LFS_CFLAGS ? (The existing test is in the
> definition of zsh_LARGE_FILE_SUPPORT in aczsh.m4.)
>
>
Hmm ... they both have very different semantic. LFS means, use existing
interfaces but assume some parameters are 64 bit (off_t, size_t, ino_t to
name some).
LFS64 means - you are explicitly using special 64-bit version of these
interfaces (open64 vs. open, stat64 vs. stat etc) that are using special
types (off64_t, ino64_t etc). Zsh is not designed to do it.
So, if the above change really helped, it was just because zsh was
actually compiled in 32-bit mode :-) We simply need better detection if
LFS really works. Could you provide testcase suitable for putting in
configure?
-andrej
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 64-bit sparc instructions
2001-05-23 9:38 ` Andrej Borsenkow
@ 2001-05-23 16:42 ` Clint Adams
0 siblings, 0 replies; 6+ messages in thread
From: Clint Adams @ 2001-05-23 16:42 UTC (permalink / raw)
To: Andrej Borsenkow; +Cc: zsh-workers, Paul Ackersviller
> So, if the above change really helped, it was just because zsh was
> actually compiled in 32-bit mode :-) We simply need better detection if
> LFS really works. Could you provide testcase suitable for putting in
> configure?
Incidentally, I have the same problems with --disable-lfs.
I'd be more inclined to blame this on the compiler, but trying
64-bit compilation on an UltraSPARC III running Debian and
gcc version 3.0 20010426 (Debian prerelease), and statically-linking:
cd Test ; make check
make[1]: Entering directory `/tmp/obj/Test'
if test -n "gcc-3.0 -mcpu=ultrasparc -m64"; then \
cd .. && \
make MODDIR=`pwd`/Test/Modules install.modules > /dev/null; \
fi
for f in ../../zsh-4.0.1-pre-5/Test/*.ztst; do \
../Src/zsh +Z -f ../../zsh-4.0.1-pre-5/Test/ztst.zsh $f; \
done
../../zsh-4.0.1-pre-5/Test/A01grammar.ztst: starting.
This test hangs the shell when it fails...
../../zsh-4.0.1-pre-5/Test/A01grammar.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/A02alias.ztst: starting.
../../zsh-4.0.1-pre-5/Test/A02alias.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/A03quoting.ztst: starting.
../../zsh-4.0.1-pre-5/Test/A03quoting.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/A04redirect.ztst: starting.
../../zsh-4.0.1-pre-5/Test/A04redirect.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/A05execution.ztst: starting.
../../zsh-4.0.1-pre-5/Test/A05execution.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/B01cd.ztst: starting.
../../zsh-4.0.1-pre-5/Test/B01cd.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/C01arith.ztst: starting.
../../zsh-4.0.1-pre-5/Test/C01arith.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/C02cond.ztst: starting.
../../zsh-4.0.1-pre-5/Test/C02cond.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/C03traps.ztst: starting.
This test takes at least three seconds...
This test, too, takes at least three seconds...
../../zsh-4.0.1-pre-5/Test/C03traps.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/C04funcdef.ztst: starting.
../../zsh-4.0.1-pre-5/Test/C04funcdef.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/D01prompt.ztst: starting.
../../zsh-4.0.1-pre-5/Test/D01prompt.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/D02glob.ztst: starting.
*** /tmp/zsh.ztst.out.10870 Wed May 23 16:32:13 2001
--- /tmp/zsh.ztst.tout.10870 Wed May 23 16:32:13 2001
***************
*** 101,107 ****
1: [[ BAR = (bar|(#i)foo) ]]
0: [[ FOO = (bar|(#i)foo) ]]
0: [[ Modules = (#i)*m* ]]
! 0: [[ fooGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]]
1: [[ FOOGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]]
0: [[ readme = (#i)readme~README|readme ]]
0: [[ readme = (#i)readme~README|readme~README ]]
--- 101,108 ----
1: [[ BAR = (bar|(#i)foo) ]]
0: [[ FOO = (bar|(#i)foo) ]]
0: [[ Modules = (#i)*m* ]]
! 1: [[ fooGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]]
! Test failed: [[ fooGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]]
1: [[ FOOGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]]
0: [[ readme = (#i)readme~README|readme ]]
0: [[ readme = (#i)readme~README|readme~README ]]
***************
*** 151,154 ****
1: [[ path/testy = *((#s)|/)test((#e)|/)* ]]
1: [[ path/testy/ohyes = *((#s)|/)test((#e)|/)* ]]
1: [[ path/atest/ohyes = *((#s)|/)test((#e)|/)* ]]
! 0 tests failed.
--- 152,155 ----
1: [[ path/testy = *((#s)|/)test((#e)|/)* ]]
1: [[ path/testy/ohyes = *((#s)|/)test((#e)|/)* ]]
1: [[ path/atest/ohyes = *((#s)|/)test((#e)|/)* ]]
! 1 tests failed.
Test ../../zsh-4.0.1-pre-5/Test/D02glob.ztst failed: output differs from expected as shown above for:
globtest globtests
Was testing: zsh globbing
../../zsh-4.0.1-pre-5/Test/D02glob.ztst: test failed.
../../zsh-4.0.1-pre-5/Test/D03procsubst.ztst: starting.
../../zsh-4.0.1-pre-5/Test/D03procsubst.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/D04parameter.ztst: starting.
../../zsh-4.0.1-pre-5/Test/D04parameter.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/D05array.ztst: starting.
../../zsh-4.0.1-pre-5/Test/D05array.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/D06subscript.ztst: starting.
../../zsh-4.0.1-pre-5/Test/D06subscript.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/E01options.ztst: starting.
../../zsh-4.0.1-pre-5/Test/E01options.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/E02xtrace.ztst: starting.
../../zsh-4.0.1-pre-5/Test/E02xtrace.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/V01zmodload.ztst: starting.
Warning: zsh/example not linked: not checking autoloading
../../zsh-4.0.1-pre-5/Test/V01zmodload.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/V02zregexparse.ztst: starting.
../../zsh-4.0.1-pre-5/Test/V02zregexparse.ztst: all tests successful.
../../zsh-4.0.1-pre-5/Test/Y01completion.ztst: starting.
Test ../../zsh-4.0.1-pre-5/Test/Y01completion.ztst failed: non-zero status from preparation code:
comptestinit -z $ZTST_testdir/../Src/zsh
../../zsh-4.0.1-pre-5/Test/Y01completion.ztst: test failed.
../../zsh-4.0.1-pre-5/Test/Y02compmatch.ztst: starting.
Test ../../zsh-4.0.1-pre-5/Test/Y02compmatch.ztst failed: non-zero status from preparation code:
comptestinit -z $ZTST_testdir/../Src/zsh
../../zsh-4.0.1-pre-5/Test/Y02compmatch.ztst: test failed.
../../zsh-4.0.1-pre-5/Test/Y03arguments.ztst: starting.
Test ../../zsh-4.0.1-pre-5/Test/Y03arguments.ztst failed: bad status 1, expected 0 from:
tst_arguments ':desc1:(arg1)'
comptest $'tst \t\C-wa\t\C-war\t\C-warg\t\C-warg1\t\C-wr\t\C-wx\t \ty \t'
Error output:
comptesteval:4: command not found: zpty
comptesteval:5: command not found: zpty
comptest:2: command not found: zpty
comptest:3: command not found: zpty
Was testing: one non-option argument
../../zsh-4.0.1-pre-5/Test/Y03arguments.ztst: test failed.
rm -rf Modules .zcompdump
make[1]: Leaving directory `/tmp/obj/Test'
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 64-bit sparc instructions
2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer
2001-05-23 9:38 ` Andrej Borsenkow
@ 2001-05-23 12:29 ` Clint Adams
1 sibling, 0 replies; 6+ messages in thread
From: Clint Adams @ 2001-05-23 12:29 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
> } By replacing the latter with the former, the test [succeeds].
Did I imply that? What I meant was that it didn't help.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-05-24 4:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-24 2:24 64-bit sparc instructions nce
2001-05-24 4:49 ` Clint Adams
-- strict thread matches above, loose matches on Subject: below --
2001-05-23 3:04 vi editting troubles Paul Ackersviller
2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer
2001-05-23 9:38 ` Andrej Borsenkow
2001-05-23 16:42 ` Clint Adams
2001-05-23 12:29 ` Clint Adams
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).