gcc 3.2 is available for RedHat 7.3/mips/mipsel

gcc 3.2 is available for RedHat 7.3/mips/mipsel

[H. J. Lu]

The gcc 3.2 mips/mipsel binary rpms for RedHat 7.3 are at

ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/test/

They come from my RedHat 8.0 MIPS port. The simple install instructions
are in INSTALL. I am interested in any feedbacks.


H.J.

explain to me how this works...

[Greg Lindahl]

I have a 64-bit kernel and O32 userland.

I notice that arping gets confused because the syscall socket() is
returning 4183 instead of a reasonable value like 3... if strace()
isn't lying to me.

How do I debug this? The O32 userland calls through the socketcall()
syscall. It looks OK.

greg

Re: explain to me how this works...

[ilya]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

see arch/mips64/kernel/linux32.c

On Wed, Nov 13, 2002 at 05:42:00PM -0800, Greg Lindahl wrote:
> I have a 64-bit kernel and O32 userland.
> 
> I notice that arping gets confused because the syscall socket() is
> returning 4183 instead of a reasonable value like 3... if strace()
> isn't lying to me.
> 
> How do I debug this? The O32 userland calls through the socketcall()
> syscall. It looks OK.
> 
> greg
> 
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: explain to me how this works...

[Greg Lindahl]

I saw that a long time ago. sys_socket and sys_socketcall seem
to be written just like all the other syscalls that return an int.

> see arch/mips64/kernel/linux32.c
> 
> On Wed, Nov 13, 2002 at 05:42:00PM -0800, Greg Lindahl wrote:
> > I have a 64-bit kernel and O32 userland.
> > 
> > I notice that arping gets confused because the syscall socket() is
> > returning 4183 instead of a reasonable value like 3... if strace()
> > isn't lying to me.
> > 
> > How do I debug this? The O32 userland calls through the socketcall()
> > syscall. It looks OK.
> > 
> > greg
> > 
> > 
> > 

Re: explain to me how this works...

[Ralf Baechle]

On Wed, Nov 13, 2002 at 05:42:00PM -0800, Greg Lindahl wrote:

> I have a 64-bit kernel and O32 userland.
> 
> I notice that arping gets confused because the syscall socket() is
> returning 4183 instead of a reasonable value like 3... if strace()
> isn't lying to me.
> 
> How do I debug this? The O32 userland calls through the socketcall()
> syscall. It looks OK.

Eh?  Nothing on MIPS should use socketcall(2); we have all the calls like
socket(2), bind(2), connect(2) etc. directly in our syscall table unlike
x86 which uses this pointless wrapper for historical reasons.  We only
have socketcall(2) in the o32 syscall interface but it's a candidate for
removal as nothing we still do support and that's glibc 2.0 and higher
binaries uses it.

  Ralf

Re: explain to me how this works...

[Greg Lindahl]

On Thu, Nov 14, 2002 at 07:39:24PM +0100, Ralf Baechle wrote:

> Eh?  Nothing on MIPS should use socketcall(2);

OK, so let's say it's using socket(). How do I go about debugging
this? I mean, I can start sprinkling printks all over the place, but is
there a more clever way?

greg

Re: explain to me how this works...

[Jun Sun]

Look like a good case for using kgdb....

Jun

On Thu, Nov 14, 2002 at 11:30:45AM -0800, Greg Lindahl wrote:
> On Thu, Nov 14, 2002 at 07:39:24PM +0100, Ralf Baechle wrote:
> 
> > Eh?  Nothing on MIPS should use socketcall(2);
> 
> OK, so let's say it's using socket(). How do I go about debugging
> this? I mean, I can start sprinkling printks all over the place, but is
> there a more clever way?
> 
> greg
> 

Re: explain to me how this works...

[Ralf Baechle]

On Thu, Nov 14, 2002 at 12:07:46PM -0800, Jun Sun wrote:

> Look like a good case for using kgdb....

Unlikely to help him.  The return value 4183 of socket that he's observing
is the syscall number of socket(2).  That's making scall_o32.S the first
suspect to look at.

Greg, could this be a case of syscall restarting that you're observing?

  Ralf

Re: explain to me how this works...

[Greg Lindahl]

On Thu, Nov 14, 2002 at 09:12:51PM +0100, Ralf Baechle wrote:

> Unlikely to help him.  The return value 4183 of socket that he's observing
> is the syscall number of socket(2).

Thank you, I should have noticed that one right off.

My sprinkle of printks already tells me that strace is a liar - no
surprise there.

strace says:

socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)

printk says:

sys_socket returning 0
sys32_socket returning 0
sys_socket returning -124
sys32_socket returning -124

Note strace sees 3 syscalls. I only printk at the return statement, 
and there are 2 of those. I'll add more printks...

-- greg

Re: explain to me how this works...

[Greg Lindahl]

On Thu, Nov 14, 2002 at 01:12:32PM -0800, Greg Lindahl wrote:

> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)

strace is useless.

My problem was that CONFIG_PACKET was not set in my .config, which causes
EAFNOSUPPORT.

-- greg

Re: explain to me how this works...

[Ralf Baechle]

On Thu, Nov 14, 2002 at 01:12:32PM -0800, Greg Lindahl wrote:

> strace says:
> 
> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
> socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)
> 
> printk says:
> 
> sys_socket returning 0
> sys32_socket returning 0
> sys_socket returning -124
> sys32_socket returning -124
> 
> Note strace sees 3 syscalls. I only printk at the return statement, 
> and there are 2 of those. I'll add more printks...

This smells alot like syscall restarting.  The first two times the
syscall fails with one of ERESTARTNOHAND, ERESTARTSYS or ERESTARTNOINTR,
then the third time is fails with EAFNOSUPPORT.

Enable CONFIG_PACKET and CONFIG_NETLINK_DEV.

The only bug here is strace being to stupid to filter out syscall restarts.

  Ralf