Conference lassie::ucx

5420.0. "UCX$GETHOSTBYNAME alignment faults UCX 4.1 AXPVMS 7.1" by COMICS::EDWARDSN (Dulce et decorum est pro PDP program) Tue Apr 08 1997 06:05

I've posted this in the DEC C conference (2134) and they seem to think 
that the behaviour is embedded in UCX$GETHOSTBYNAME

DEC C is V5.5-003 on OpenVMS AXP 7.1 with...
  Digital TCP/IP Services for OpenVMS Alpha Version V4.1

Hence this:

A customer has raised the following question about alignment fault reporting
for use with socket routines and specifically gethostbyname.
It would appear that gethostbyname is performing some nasties.

Alignment faults are reported when AFR is set to buffered mode, the customer would
like to use exception mode to trap the faults, but he isn't expecting this behaviour
from gethostbyname and thus is getting exceptions raised from code which he didn't 
think he needed to check. 

Is there something which can be done about the alignment faults or is it inherent
in the datastructures which are passed in sockets? 
Can anyone assist?

Neil

The following is compiled using:

$ CC/DEB/NOOPT/PREF=ALL/DEF=AFRBUF

#include <time.h>
#include <socket.h>
#include <netdb.h>
#include <in.h>
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>

#if defined(__vms) && defined(__alpha)
#include <afrdef.h>
#include <ssdef.h>
#include <starlet.h>
#define USER_BUFFER_ITEMS  10
#define GET_BUFFER_SIZE    USER_BUFFER_ITEMS*AFR$K_USER_LENGTH
#define fault_pc afr$l_fault_pc_l
#define fault_va afr$l_fault_va_l

void note_unaligned_accesses()
{
static char save_buffer[512+64];
int sts;

#ifdef AFRBUF
sts = sys$start_align_fault_report( AFR$C_BUFFERED, save_buffer,
sizeof(save_buffer) );
#else
sts = sys$start_align_fault_report( AFR$C_EXCEPTION, NULL, 0 );
#endif
if ( sts != SS$_NORMAL )
    {
    printf( "Unable to start alignment fault reporting - status is %d\n", sts
);
   exit( sts );
    }
}

#ifdef AFRBUF
void print_unaligned_accesses()
{
  char           get_buffer[GET_BUFFER_SIZE];
  struct afrdef  *data_item;
  int            offset;
  int            status;
  int            return_size;

  while (((status = sys$get_align_fault_data (get_buffer,
                GET_BUFFER_SIZE,
                &return_size)) > 0) &&
         (return_size > 0)) {
    /* got some data, print it */
    offset = 0;
    while (offset < return_size) {
      data_item = (struct afrdef *)(&get_buffer[offset]);
      printf ("Alignment fault at PC = %8.8X, VA = %8.8X\n",
        data_item->fault_pc, data_item->fault_va);
      offset += AFR$K_USER_LENGTH;
    }
  }
}
#else
#define print_unaligned_accesses()
#endif
#else
#define note_unaligned_accesses()
#define print_unaligned_accesses()
#endif

int main ()
{
    struct hostent *ptemp;

    note_unaligned_accesses();
    ptemp = gethostbyname ("ncra") ;
    if ( ptemp == NULL )
 printf( "gethostbyname failed with status %d\n", errno );

    print_unaligned_accesses();
    return 1;
}

I'm wearing out the I, P, M, and T keys on my keyboard.

Since this is a customer issue and it looks to me like it
is going to take more than 5 minutes of someones time to look
at, the best way of getting it in someone's queue is to 
IPMT the issue.

I'm not on the UCX kernel team  (I'm an NFS type) but I have
used sockets and have chased alignment faults.  What you describe
does not surprise me. If I remember correctly gethostbyname()
returns a pointer to a structure (hostent?). Look at the structure
definition and you will probably find all sorts of stuff that
Alphas complain about.  I think that EV6 (with code compiled for it)
is supposed to be better at handling this sort of thing. 

So, as you guessed, some of the alignment faults you are seeing
may be inherent (< EV6). 

Is there a way to turn off alignment fault reporting around particular
sections of code, say any network code?

Lee
 

    >I think that EV6 (with code compiled for it)
    >is supposed to be better at handling this sort of thing.
    
    I think you are a little confused.  I assume you are thinking of the
    byte/word instructions that have been added to the latest EV56 
    chips.  I don't know of anything in EV6 that would make a difference.
    
    However, the addition of byte and word instructions into the Alpha
    architecture still won't change the behavior of executing a
    LDL or LDQ instruction whose address isn't longword or quadword
    aligned.  The new instructions just let the compiler fetch a single
    byte with a single instruction instead of fetching the surrounding
    longword/quadword and then masking and shifting the byte into
    position.  It just turns a handful of instructions into a single
    instruction.  If the code lies to the compiler and promises that
    something is aligned but really isn't, then the code has a problem.
    
    				-John

>    I think you are a little confused. 

Can I plead nolo and get a reduced sentence? .-1 is correct. 

I've gone chasing (mis) alignment in UCX Alpha code a couple
of times.  It is no simple task.  Almost all of the code was
written for VAX. My understanding is that the port to Alpha
was done under the lash.

Yes, I was hoping that the introduction of byte/word instructions
and complier support would (magically) reduce our risk here.

It is my understanding that the IPV6 code will be written for Alpha
and be two or so orders of magnitude better at alignment.  A number of
here in UCX Engineering are interested in getting this right.


Lee