WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?

To: <takebe_akio@xxxxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Mon, 7 Nov 2005 18:56:36 -0800
Delivery-date: Tue, 08 Nov 2005 02:56:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXkD2B0N/lZllyMRXakhqYVgj7TjQAAGgOA
Thread-topic: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?
Maybe you could add some code to print out every header
to ensure that the pointers are correct and the data in
the header matches objdump.  Another thought
is that maybe there is a confusion between physical address
and virtual address?

Just some ideas to try...

Dan 

> -----Original Message-----
> From: takebe_akio@xxxxxxxxxxxxxx [mailto:takebe_akio@xxxxxxxxxxxxxx] 
> Sent: Monday, November 07, 2005 7:51 PM
> To: takebe_akio@xxxxxxxxxxxxxx; Magenheimer, Dan (HP Labs 
> Fort Collins); xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?
> 
> Hi All,
> 
> I'm still tried to boot RHEL4 + Xen.
> But I have not been able to boot yet.
> 
> I confirmed to boot until the following point. 
> 
> fs/binfmt_elf.c
> -------------------------
>  static int load_elf_binary(struct linux_binprm * bprm, 
> struct pt_regs * regs)
>  {
> 
>  snip...
> 
>          for (i = 0; i < loc->elf_ex.e_phnum; i++) {
>                  if (elf_ppnt->p_type == PT_INTERP) {
>                          /* This is the program interpreter used for
>                           * shared libraries - for now assume 
> that this
>                           * is an a.out format binary
>                           */
>  
>                          retval = -ENOEXEC;
>                          if (elf_ppnt->p_filesz > PATH_MAX || 
>                              elf_ppnt->p_filesz < 2)
>                                  goto out_free_file;
>                          retval = -ENOMEM;
>                          elf_interpreter = (char *) 
> kmalloc(elf_ppnt->p_filesz,
>                                                             
> GFP_KERNEL);
>                          if (!elf_interpreter)
>                                  goto out_free_file;
>  
>                          retval = kernel_read(bprm->file, 
> elf_ppnt->p_offset,
>                                             elf_interpreter,
>                                             elf_ppnt->p_filesz);
>                          if (retval != elf_ppnt->p_filesz) {
>                                  if (retval >= 0)
>                                          retval = -EIO;
>                                  goto out_free_interp;
>                          }
>                          /* make sure path is NULL terminated */
>                          retval = -ENOEXEC;
>                          if 
> (elf_interpreter[elf_ppnt->p_filesz - 1] != '\0')
>                                  goto out_free_interp;
>  
>                          /* If the program interpreter is one 
> of these two,
>                           * then assume an iBCS2 image. 
> Otherwise assume
>                           * a native linux image.
>                           */
>                          if 
> (strcmp(elf_interpreter,"/usr/lib/libc.so.1") == 0 ||
>                              
> strcmp(elf_interpreter,"/usr/lib/ld.so.1") == 0)
>                                  ibcs2_interpreter = 1;
>  
>                          /*
>                           * The early SET_PERSONALITY here is 
> so that the lookup
>                           * for the interpreter happens in 
> the namespace of the 
>                           * to-be-execed image.  
> SET_PERSONALITY can select an
>                           * alternate root.
>                           *
>                           * However, SET_PERSONALITY is NOT 
> allowed to switch
>                           * this task into the new images's 
> memory mapping
>                           * policy - that is, TASK_SIZE must 
> still evaluate to
>                           * that which is appropriate to the 
> execing application.
>                           * This is because exit_mmap() needs 
> to have TASK_SIZE
>                           * evaluate to the size of the old image.
>                           *
>                           * So if (say) a 64-bit application 
> is execing a 32-bit
>                           * application it is the 
> architecture's responsibility
>                           * to defer changing the value of 
> TASK_SIZE until the
>                           * switch really is going to happen 
> - do this in
>                           * flush_thread().      - akpm
>                           */
>                          SET_PERSONALITY(loc->elf_ex, 
> ibcs2_interpreter);
>  
>                          interpreter = open_exec(elf_interpreter);
>                          retval = PTR_ERR(interpreter);
>                          if (IS_ERR(interpreter))
>                                  goto out_free_interp;
>                          retval = kernel_read(interpreter, 0, 
> bprm->buf, BINPRM_BUF_SIZE);  <---HERE !!!!!
>                          if (retval != BINPRM_BUF_SIZE) {
>                                  if (retval >= 0)
>                                          retval = -EIO;
>                                  goto out_free_dentry;
>                          }
>  
>                          /* Get the exec headers */
>                          loc->interp_ex = *((struct exec *) 
> bprm->buf);
>                          loc->interp_elf_ex = *((struct 
> elfhdr *) bprm->buf);
>                          break;
>                  }
>                  elf_ppnt++;
>          }
>   snip...
> -------------
> 
> The above for loop is available when there is .interp section 
> in ELF binary.
> .interp section is found, then enter if section and the 
> following operation do.
>  1. Check "if (elf_ppnt->p_filesz > PATH_MAX || 
> elf_ppnt->p_filesz < 2)"
>  2. Alloc memory for pasting a library path by using kmalloc().
>  3. Read a library path from /sbin/init by using kernel_read()
>  4. Check wheather /usr/lib/libc.so.1 or /usr/lib/ld.so.1
>  5. Open the library by using open_exec()
>  6. Read the library from head to BINPRM_BUF_SIZE(128)
>  7. Substitute the library header and Break
> 
> contents of .interp section are below.
> =====================
> # LANG=C objdump -s -j .interp /sbin/init
> 
> /sbin/init:     file format elf64-ia64-little
> 
> Contents of section .interp:
>  4000000000000200 2f6c6962 2f6c642d 6c696e75 782d6961  
> /lib/ld-linux-ia
>  4000000000000210 36342e73 6f2e3200                    64.so.2.    
> =====================
> 
>  /lib/ld-linux-ia64.so.2 is symbolic link
> =====================
> # LANG=C ls -l /lib/ld-linux-ia64.so.2
> lrwxrwxrwx  1 root root 11 Oct 25 23:27 
> /lib/ld-linux-ia64.so.2 -> ld-2.3.4.so
> =====================
> 
> I think 0 -> 128 byte of the ld-2.3.4.so is ELF header. 
> The header of the ld-2.3.4.so is the below.
> =====================
> # readelf -h /lib/ld-2.3.4.so |less
> ELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
>   Class:                             ELF64
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              DYN (Shared object file)
>   Machine:                           Intel IA-64
>   Version:                           0x1
>   Entry point address:               0x2c90
>   Start of program headers:          64 (bytes into file)
>   Start of section headers:          205448 (bytes into file)
>   Flags:                             0x10, 64-bit
>   Size of this header:               64 (bytes)
>   Size of program headers:           56 (bytes)
>   Number of program headers:         5
>   Size of section headers:           64 (bytes)
>   Number of section headers:         25
>   Section header string table index: 22
> =====================
> 
> Why the header cannot be read?
> Any idea? It's very difficult. Hmmm.... :<
> 
> Best Regards,
> 
> Akio takebe
> 
> 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel