OSF/1 port...

[Gareth Pearce]

Hi,
I might be in a bit over my head (hmm more like definitely but anyway)... 
but I have been giving resurrecting the OSF/1 port a go.
Given that I have very limited experience in assembler on OSF, and had never 
looked at a libc codebase before thursday ... I dont think I am going too 
badly... (easy to port - looks like it might be right :P)
I have been making my ugly hacks to 2.2.5 (guess using cvs wouldnt of hurt) 
- and have made it to the point where i have a libc.a ...
Admitedly its a non-functioning libc.a - several unresolved symbols which 
cause the following tool building section to fail.

Anyway, I was wondering if submitting some of my patches (updated against 
2.3 and deuglified) to CVS ... might prompt greater progress since they 
would get looked at by people who know something about libc - and prehaps 
pull people with knowledge of OSF out of the woodwork (since i dont know 
anything much yet on that front either :P).

while i am here ... I guess I might ask a quesstion or 2...
my list of unresolveds at first failure is
__pthread_mutex_unlock
__pthread_mutex_lock
_dl_mcount_wrapper_check
__getdents
__syscall_stat
__syscall_fstat
__libc_open
__libc_dlopen
__libc_dlsym
__libc_dlclose
__syscall_lstat
syscall_error

now i expected the pthread ones ... since i started using pthread_mutex_t 
for mutexs for libc_lock stuffs ... (which i think might be a very 'bad' 
thing - but it compiled :P - I couldnt see how linux got around this 
either... - prehaps something to cause a kernel lock to be set?)
the syscall_stat etc, i have tried to look at how other ports manage to get 
these defined ... but left me a bit confused - my first guess is that I 
could just write a .S file like several other syscalls (looks easy enough) - 
or should i be doing something with syscalls.list files?
syscall_error looks easy - just need to alias it to __syscall_error
libc_* and dl_mcount_wrapper_check - are ... where i need to learn alot of 
stuff i think *chuckle* - since I know nothing about the shared library 
format/support on OSF/1 yet...
not sure whats going on with __getdents - hmm i see generic file doesnt deal 
with it.- guess that one should be easy enough to fix.

other things i suspect wrong - i probably stuffed the atomicity.S in order 
to get it to assemble on a non-elf - non-gas assembler. (having a non-gas 
assembler is a tiny pain - number labels can only be between 1-255 - 0 being 
all to common)
I cant find the syscall number for getppid for OSF/1- anywhere - which seems 
rather odd. (life might be easier if the kernel was open source heheh)
no strong_alias's on this platform, they all have to be weak... - as far as 
I can tell, (no idea if this is going to cause pain in the long run)
I am guessing that the configure/build scripts are out of date for OSF ... 
havent looked at them closely at all yet.

sure that wont be the end of it... but i at least have this fake feeling of 
progress.:)

Regards,
Gareth Pearce

--subscribed to libc-alpha - but not to bug-glibc...



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com