irix 6.2 libc.so inet_ntoa() bug?
cees-bart
I noticed when running exim and sshd on my indy running irix 6.2 that the
logs and mailheaders on my host were clobbered with '255.255.255.255' ip
addresses.
Some digging showed me that calling inet_ntoa() with a valid in_addr
struct returns a string "255.255.255.255", no matter what the IP-address
in the struct is. Is this some ancient bug? I couldn't find any libc
patches though.
bye,
cees.
Walter Roberson
cees-bart <foz...@hete.nattedozen.nl> wrote:
:I noticed when running exim and sshd on my indy running irix 6.2 that the
The bug is in the gcc used to compile the programs, not in IRIX.
Bob Beaty
> I noticed when running exim and sshd on my indy running irix 6.2 that
the
> logs and mailheaders on my host were clobbered with '255.255.255.255'
ip
> addresses.
>
> Some digging showed me that calling inet_ntoa() with a valid in_addr
> struct returns a string "255.255.255.255", no matter what the
IP-address
> in the struct is.
Actually, this could be a consequence of a GCC problem on Irix. As I
understand it, the inet_ntoa() returns a struct that is 'too' small and
it doesn't get passed correctly. If the exim and sshd were compiled with
gcc, this might be the problem.
There's no real fix that I've heard of other than to patch the gcc code
for inet_ntoa() and then rebuild gcc, and then rebuild exim and sshd.
Thanks,
Bob (bobb...@mediaone.net)
The Man from S.P.U.D.
We will write no code before it's designed.
Andrew Zhilenko
Bob Beaty wrote:
> Actually, this could be a consequence of a GCC problem on Irix. As I
> understand it, the inet_ntoa() returns a struct that is 'too' small and
> it doesn't get passed correctly. If the exim and sshd were compiled with
> gcc, this might be the problem.
>
> There's no real fix that I've heard of other than to patch the gcc code
> for inet_ntoa() and then rebuild gcc, and then rebuild exim and sshd.
Does anybody know more about this? Any chance, that it was fixed in
recent releases of GCC (2.95.2?)?
Because it is quite painful (and nearly impossible) to compile some
programs with native compiler :-(
WBR, Andrew
--
Andrew Zhilenko, AZ283-RIPE, System Administrator
Telenor Internet
tel.+42-02-96159436 fax. +42-02-96159422
e-mail: and...@ti.cz http://i.am/manowar/
Vaclavske namesti 4 - Praha 1 - 110 00
Czech Republic
Randolph J. Herber
|Bob Beaty wrote:
|> Actually, this could be a consequence of a GCC problem on Irix. As I
|> understand it, the inet_ntoa() returns a struct that is 'too' small and
|> it doesn't get passed correctly. If the exim and sshd were compiled with
|> gcc, this might be the problem.
|> There's no real fix that I've heard of other than to patch the gcc code
|> for inet_ntoa() and then rebuild gcc, and then rebuild exim and sshd.
|Does anybody know more about this? Any chance, that it was fixed in
|recent releases of GCC (2.95.2?)?
It is caused by returning by value a structure small enough
to fit into a register. SGI compiled code does pass it in
a register; the GCC compiled code expects such structures
to be passed on the stack, as larger structures are.
Write your own version of inet_ntoa that returns its value
by some other means.
|Because it is quite painful (and nearly impossible) to compile some
|programs with native compiler :-(
No, 8^}. GCC is not C++. Unfortunately, it has many
``enhancements'' which are not part of the C++ standard
and which amateur programmers use to write their programs.
|WBR, Andrew
|Andrew Zhilenko, AZ283-RIPE, System Administrator
| Telenor Internet
|tel.+42-02-96159436 fax. +42-02-96159422
|e-mail: and...@ti.cz http://i.am/manowar/
|Vaclavske namesti 4 - Praha 1 - 110 00
| Czech Republic
Randolph J. Herber, her...@dcdrjh.fnal.gov, +1 630 840 2966, CD/CDFTF PK-149F,
Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500,
USA. (Speaking for myself and not for US, US DOE, FNAL nor URA.) (Product,
trade, or service marks herein belong to their respective owners.)
Stuart Levy
>Hello!
>
>Bob Beaty wrote:
>
>> Actually, this could be a consequence of a GCC problem on Irix. As I
>> understand it, the inet_ntoa() returns a struct that is 'too' small and
>> it doesn't get passed correctly. If the exim and sshd were compiled with
>> gcc, this might be the problem.
>>
>> There's no real fix that I've heard of other than to patch the gcc code
>> for inet_ntoa() and then rebuild gcc, and then rebuild exim and sshd.
>Does anybody know more about this? Any chance, that it was fixed in
>recent releases of GCC (2.95.2?)?
>programs with native compiler :-(
Although the gcc gurus say this problem is very hard to fix in
the compiler, it fortunately only seems to affect a very few routines.
Since the problem is that the gcc-generated calling sequence is
compatible with itself but (in very limited circumstances) is
incompatible with the SGI-compiled lib*.{so,a},
it's an adequate workaround to provide gcc-compiled versions
of the affected routines.
I searched for these and could only find a few examples where
library routines take structures by value. The dbm routines do,
but they use 8-byte structures, so gcc and SGI cc should agree.
semctl() takes what appears to be a 4-byte union. Since it's a
system call, one might have to decompile the SGI version and
write an assembly-language replacement to get a gcc-compatible version.
I've never tried this.
Fortunately, inet_ntoa (and inet_lnaof() and inet_netof()) don't do
any magic -- you can easily write a replacement and just hack it
into the program's source somewhere. Compiling the version below
using gcc worked for me with ssh and the MBone tools.
Gee, maybe it'd be worth incorporating such hacks into libgcc.a,
since all gcc-compiled programs are going to link with it anyway.
#if sgi && __GNUC__
/* Replacement for SGI libc inet_ntoa(), since
* gcc's structure-passing convention isn't the same as SGI cc's.
*/
char *inet_ntoa( struct in_addr sa )
{
static char addr[20];
sprintf(addr, "%d.%d.%d.%d",
((unsigned char *)&sa.s_addr)[0], ((unsigned char *)&sa.s_addr)[1],
((unsigned char *)&sa.s_addr)[2], ((unsigned char *)&sa.s_addr)[3]);
return addr;
}
#endif
I've posted about this before -- most recently last Dec 13, look for
"inet_ntoa" -- but am reposting since semctl() is news (to me anyway).
- Stuart Levy, sl...@ncsa.uiuc.edu
University of Illinois Urbana-Champaign
Alexis Cousein
>
> Hello!
>
> "Tarjei T. Jensen" wrote:
>
> > You should try gcc 2.95.x. I seem to remember that it works better with the
> > network libraries. One place to find a binary version is at
> > ftp://ftp.thewrittenword.com/free/by-package/ they have different Irix
> Thanks for link, it's really good collection of packages... But problem
> persist. When using wu-ftpd 2.6.0 as a test guinea pig:
> - wu-ftpd compiled with gcc 2.8.1 from freeware.sgi.com on Challenge S,
> IRIX 6.5.6 was printing 255.255.255.255 instead of addresses
> - wu-ftpd compiled with gcc 2.95.2 on Indy, IRIX 6.5.6 is printing 0.0.0.0
> instead of addresses :-(
There are a few possible fixes:
-compile inet_ntoa from source using GCC, so as to use the same
(incorrect) convention instead of the normal MIPS N32 ABI spec for
passing the offending structs.
-compile using an older GCC (2.7.x) and the O32 ABI.
-compile using the N64 MIPS ABI of GCC instead of N32; it doesn't have
the same bug. Yes, it doesn't always work if you have other things to
link in that are N32.
--
<standard disclaimer: these are my personal views, not SGI's>
Alexis Cousein a...@brussels.sgi.com
Systems Engineer SGI Belgium