ports/emulators/linux_base on amd64

[Sean McNeil]

On Tue, 2004-12-14 at 14:13 -0800, Sean McNeil wrote:
> On Tue, 2004-12-14 at 23:54 +0200, Ruslan Ermilov wrote:
> > On Tue, Dec 14, 2004 at 10:34:06AM -0800, Sean McNeil wrote:
> > [...]
> > > rpm scripts should also be fixed.  It seems like a bug in the rpm port
> > > that no one has addressed.
> > > 
> > rpm port is not guilty -- running the postinstall script
> > manually on amd64 returns 1, but on i386 it returns 0:
> > 
> > Script started on Tue Dec 14 23:10:31 2004
> > hammer#	/compat/linux/bin/sh
> > sh-2.04# uname -srm
> > Linux 2.4.2 amd64
> > sh-2.04# /usr/sbin/glibc_post_upgrade 
> > sh-2.04# echo $?
> > 1
> > Script done on Tue Dec 14 23:10:53 2004
> 
> Yes, I just got to this point.  Thanks for the confirmation.  I'm trying
> to find sources to glibc_post_upgrade to take a look.

Here is what I have so far....

The source looks like this:

#ifdef ARCH_386
  /* Work around rpm bug */
  char *remove_file[] = {
    "/lib/i686/libc-" VERSION ".so",
    "/lib/i686/libm-" VERSION ".so",
    "/lib/i686/libpthread-" PVERSION ".so",
    "/lib/i686/libc.so.6",
    "/lib/i686/libm.so.6",
    "/lib/i686/libpthread.so.0",
    NULL };
  int i;

  for (i = 0; remove_file[i]; i++)
    unlink (remove_file[i]);
#endif
  pid = vfork ();
  if (pid == 0) {
    execl ("/sbin/ldconfig", "/sbin/ldconfig", NULL);
    _exit (1);
  } else if (pid < 0) {
    _exit (1);
  }
  if (waitpid (0, &status, 0) != pid || !WIFEXITED (status)) {
    _exit (1);
  }
  if (WEXITSTATUS (status))
    _exit (WEXITSTATUS (status));

ktrace shows:

  2018 ktrace   RET   ktrace 0
  2018 ktrace   CALL
execve(0x7fffffffee0f,0x7fffffffec60,0x7fffffffec70)
  2018 ktrace   NAMI  "/compat/linux/usr/sbin/glibc_post_upgrade"
  2018 glibc_post_upgrade RET   execve 0
  2018 glibc_post_upgrade CALL  unlink(0x8048788)
  2018 glibc_post_upgrade NAMI  "/compat/linux/lib/i686/libc-2.2.4.so"
  2018 glibc_post_upgrade NAMI  "/lib/i686/libc-2.2.4.so"
  2018 glibc_post_upgrade RET   unlink JUSTRETURN
  2018 glibc_post_upgrade CALL  unlink(0x80487a0)
  2018 glibc_post_upgrade NAMI  "/compat/linux/lib/i686/libm-2.2.4.so"
  2018 glibc_post_upgrade NAMI  "/lib/i686/libm-2.2.4.so"
  2018 glibc_post_upgrade RET   unlink JUSTRETURN
  2018 glibc_post_upgrade CALL  unlink(0x80487b8)
  2018 glibc_post_upgrade NAMI
"/compat/linux/lib/i686/libpthread-0.9.so"
  2018 glibc_post_upgrade NAMI  "/lib/i686/libpthread-0.9.so"
  2018 glibc_post_upgrade RET   unlink JUSTRETURN
  2018 glibc_post_upgrade CALL  unlink(0x80487d4)
  2018 glibc_post_upgrade NAMI  "/compat/linux/lib/i686/libc.so.6"
  2018 glibc_post_upgrade NAMI  "/lib/i686/libc.so.6"
  2018 glibc_post_upgrade RET   unlink JUSTRETURN
  2018 glibc_post_upgrade CALL  unlink(0x80487e8)
  2018 glibc_post_upgrade NAMI  "/compat/linux/lib/i686/libm.so.6"
  2018 glibc_post_upgrade NAMI  "/lib/i686/libm.so.6"
  2018 glibc_post_upgrade RET   unlink JUSTRETURN
  2018 glibc_post_upgrade CALL  unlink(0x80487fc)
  2018 glibc_post_upgrade NAMI  "/compat/linux/lib/i686/libpthread.so.0"
  2018 glibc_post_upgrade NAMI  "/lib/i686/libpthread.so.0"
  2018 glibc_post_upgrade RET   unlink JUSTRETURN
  2018 glibc_post_upgrade CALL  lstat
  2018 glibc_post_upgrade RET   lstat 2019/0x7e3
  2018 glibc_post_upgrade CALL  old.sendmsg(0,0xffffdb8c,0,0)
  2018 glibc_post_upgrade RET   old.sendmsg 2019/0x7e3
  2018 glibc_post_upgrade CALL  exit(0x1)

Looks like there is a mismatch in kernel entry points here.

lstat instead of vfork and old.sendmsg instead of (maybe) waitpid.

Does ktrace work with linux abi?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20041214/dedd4e44/attachment.bin