For current releases
Current Debian and Ubuntu have multiarch support: You can mix x86_32 (i386) and x86_64 (amd64) packages on the same system in a straightforward way. This is known as multiarch support -
see Ubuntu or Debian wiki more information.
See warl0ck's answer for a simple, up-to-date answer.
For old releases
In older releases, Debian and Ubuntu ship with a number of 32-bit libraries on amd64. Install the ia32-libs 
package to have a basic set of 32-bit libraries, and possibly other packages that depend on this one. Your 32-bit executables should simply run if you have all the required libraries. For development, install gcc-multilib , and again possibly other packages that depend on it such as g++-multilib. You may find binutils-multiarch useful as well, and ia32-libs-dev on Debian. Pass the -m32 option to gcc to compile for ix86.
Note that uname -m will still show x64_64 if you're running a 64-bit kernel, regardless of what 32-bit user mode components you have installed. Schroot described below takes care of this.
Schroot
This section is a guide to installing a Debian-like distribution “inside” another Linux distribution. It is worded in terms of installing a 32-bit Ubuntu inside a 64-bit Ubuntu, but should apply with minor modifications to other situations, such as installing Debian unstable inside Debian stable or vice versa.
Introduction
The idea is to install an alternate distribution in a subtree and run from that. You can install a 32-bit system on a 64-bit system that way, or a different release of your distribution, or a testing environment with different sets of packages installed.
The chroot command and system call starts a process with a view of the filesystem that's restricted to a subtree of the directory tree. Debian and Ubuntu ship schroot, a utility that wraps around this feature to create a more usable sub-environment.
Install the schroot package (Debian) and the debootstrap package (Debian). Debootstrap is only needed for the installation of the alternate distribution and can be removed afterwards.
Set up schroot
This example describes how to set up a 32-bit Ubuntu 10.04LTS (lucid lynx) alternate environment. A similar setup should work with other releases of Debian and Ubuntu. Create a file /etc/schroot/chroot.d/lucid32 with the following contents:
[lucid32]
description=Ubuntu 10.04LTS 32-bit
directory=/32
type=directory
personality=linux32
users=yourusername
groups=users,admin
The line directory=/32 tells schroot where we'll put the files of the 32-bit installation. The line username=yourusername says the user yourusername will be allowed to use the schroot. The line groups=users,admin says that users in either group will be allowed to use the schroot; you can also put a users=… directive.
Install the new distribution
Create the directory and start populating it with debootstrap. Debootstrap downloads and installs a core set of packages for the specified distribution and architecture.
mkdir /32
debootstrap --arch i386 lucid /32 http://archive.ubuntu.com/ubuntu
You almost have a working system already; what follows is minor enhancements. Schroot automatically overwrites several files in /32/etc when you run it, in particular the DNS configuration in /etc/resolv.conf and the user database in /etc/passwd and other files (this can be overridden, see the documentation). There are a few more files you may want to copy manually once and for all:
cp -p /etc/apt/apt.conf /32/etc/apt/ # for proxy settings
cp -p /etc/apt/sources.list /32/etc/apt/ # for universe, security, etc
cp -p /etc/environment /32/etc/ # for proxy and locale settings
cp -p /etc/sudoers /32/etc/ # for custom sudo settings
There won't be a file /etc/mtab or /etc/fstab in the chroot. I don't recommend using the mount command manually in the chroot, do it from outside. But do create a good-enough /etc/mtab to make commands such as df work reasonably.
ln -s /proc/mounts /32/etc/mtab
With the directory type, schroot will perform bind mounts of a number of directories, i.e. those directories will be shared with the parent installation: /proc, /dev, /home, /tmp.
Services in the chroot
As described here, a schroot is not suitable for running daemons. Programs in the schroot will be killed when you exit the schroot. Use a “plain” schroot instead of a “directory” schroot if you want it to be more permanent, and set up permanent bind mounts in /etc/fstab on the parent installation.
On Debian and Ubuntu, services start automatically on installation. To avoid this (which could disrupt the services running outside the chroot, in particular because network ports are shared), establish a policy of not running services in the chroot. Put the following script as /32/usr/sbin/policy-rc.d and make it executable (chmod a+rx /32/usr/sbin/policy-rc.d).
#!/bin/sh
## Don't start any service if running in a chroot.
## See /usr/share/doc/sysv-rc/README.policy-rc.d.gz
if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
exit 101
fi
Populate the new system
Now we can start using the chroot. You'll want to install a few more packages at this point.
schroot -c lucid32
sudo apt-get update
apt-get install lsb-core nano
...
You may need to generate a few locales, e.g.
locale-gen en_US en_US.utf8
If the schroot is for an older release of Ubuntu such as 8.04 (hardy), note that the package ubuntu-standard pulls in an MTA. Select nullmailer instead of the default postfix (you may want your chroot to send mail but you definitely don't want it to receive any).
Going further
For more information, see the schroot manual, the schroot FAQ and the
schroot.conf manual. Schroot is part of the Debian autobuilder (buildd) project. There may be additional useful tips on the Ubuntu community page about debootstrap.
Virtual machine
If you need complete isolation of the alternate environment, use a virtual machine such as KVM (qemu-kvm ) or VirtualBox.
With regard to eclipse not being able to find adb, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.
With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd on on sdk/platform-tools/adb:
linux-gate.so.1 => (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)
Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:
»file /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
»file /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]
A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd. I don't have an example at hand, but if something is missing ldd reports something like:
libc.so.6 => ??????
First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):
»yum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.
You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides / yum search should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).
Quick tip about using whatprovides:
»yum whatprovides libtinfo
No matches found.
»yum whatprovides libtinfo.so.5
[2 matches]
»yum whatprovides "*/libtinfo.so.5"
[4 matches]
;)
Best Answer
Running 64-bit applications requires some support from the kernel: the kernel needs to at least set up page tables, interrupt tables etc. as necessary to support running 64-bit code on the CPU, and it needs to save the full 64-bit context when switching between applications (and from applications to the kernel and back). Thus a purely 32-bit kernel can’t support 64-bit userspace.
However a kernel can run 32-bit code in kernel space, while supporting 64-bit code in user space. That involves handling similar to the support required to run 32-bit applications with a 64-bit kernel: basically, the kernel has to support the 64-bit interfaces the applications expect. For example, it has to provide some mechanism for 64-bit code to call into the kernel, and preserve the meaning of the parameters (in both directions).
The question then is whether it’s worth it. On the Mac, and some other systems, a case can be made since supporting 32-bit kernel code means drivers don’t all have to make the switch simultaneously. On Linux the development model is different: anything in the kernel is migrated as necessary when large changes are made, and anything outside the kernel isn’t really supported by the kernel developers. Supporting 32-bit userland with a 64-bit kernel is certainly useful and worth the effort (at least, it was when x86-64 support was added), I’m not sure there’s a case to be made for 64-bit on 32-bit...