Unable to run executable built using gcc

I have setup a new environment - it's a chroot containing Ubuntu 14.04 (trusty) in a Chromebook (Asus flip C100P - ARM based). I've got gcc and g++ installed. I created a simple "hello, world" program (test.c) and compiled it via:

 gcc -o t.exe test.c

When I go to run ./t1.exe, I get the following:

bash: ./t.exe: Permission denied

Note that I was executing as root and the permissions on ./t.exe is set wide open (chmod 777, verified via ls -l).

So I tried determining what's wrong - here's what I've tried:

% file ./t.exe

./t.exe: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=82a6c6227e0f7171a68c71a74c6e6396e37e6675, not stripped

% ldd ./t.exe

not a dynamic executable

% readelf -d ./t.exe | grep NEEDED

0x00000001 (NEEDED)                     Shared library: [libc.so.6]

% dpkg -l libc6

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  libc6:armhf    2.19-0ubuntu armhf        Embedded GNU C Library: Shared li

% cat /etc/ld.so.conf.d/*

# Multiarch support
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf/mesa-egl
/usr/lib/arm-linux-gnueabihf/mesa
/usr/lib/arm-linux-gnueabihf/libfakeroot
# libc default configuration
/usr/local/lib

% ls -l libc.so.6

lrwxrwxrwx 1 root root 14 Aug 12 19:37 libc.so.6 -> /lib/libc.so.6

% ls -l /usr/local/lib/libc.so.6

lrwxrwxrwx 1 root root 14 Aug 12 18:21 /usr/local/lib/libc.so.6 -> /lib/libc.so.6

% ls -l /usr/lib/libc.so.6

lrwxrwxrwx 1 root root 14 Aug 12 19:37 /usr/lib/libc.so.6 -> /lib/libc.so.6

% ls -l /lib/libc.so.6

lrwxrwxrwx 1 root root 34 Aug 12 18:11 /lib/libc.so.6 -> /lib/arm-linux-gnueabihf/libc.so.6

% ls -l /lib/arm-linux-gnueabihf/libc.so.6

lrwxrwxrwx 1 root root 12 May 26 07:55 /lib/arm-linux-gnueabihf/libc.so.6 -> libc-2.19.so

% ls -l /lib/arm-linux-gnueabihf/libc-2.19.so

-rwxr-xr-x 1 root root 902876 May 26 07:56 /lib/arm-linux-gnueabihf/libc-2.19.so

% objdump -a /lib/arm-linux-gnueabihf/libc-2.19.so

/lib/arm-linux-gnueabihf/libc-2.19.so:     file format elf32-littlearm

/lib/arm-linux-gnueabihf/libc-2.19.so

% objdump -a ./t.exe

./t.exe:     file format elf32-littlearm

./t.exe

% uname -a

Linux localhost 3.14.0 #1 SMP PREEMPT Tue Aug 2 21:07:06 PDT 2016 armv7l armv7l armv7l GNU/Linux

I suspect that I've got a borked toolchain, but I'm truly stumped at this point.
Does anyone have any ideas on what's going on here or how to proceed in finding the problem?

So it turns out that I was originally using a directory on a removable SD card, and I had used that card to house my encrypted chroot as well. (Not recommended BTW - very slow.) This directory was therefore visible and reachable by ChromeOS and Ubuntu, without explicitly setting up a share.

Looking online for an answer, I stumbled across the following: https://ubuntuforums.org/showthread.php?t=1956802. It turns out that my /etc/fstab file was effectively empty - containing only "# UNCONFIGURED FSTAB FOR BASE SYSTEM" in it.

Looking at the output from 'mount', it appears that the file system on the SD card is mounted with 'noexec'. I believe this is the source of my problems - I think I could add an fstab entry for this filesystem with the 'exec' flag instead, and everything should work.

Thinking about this further, however, I decided not to do this - after all, I only need items in the encrypted file systems (which are container files on the SD card) to allow execution of files, and making the files on the SD card file system directly executable may be slightly less secure. Therefore, I decided to simply change the directory tree I use for development work to be under my user home directory (which is in the encrypted file system used by Ubuntu in the chroot, and is apparently located on the SD card in a container file, but not directly in the file system on the SD card partition itself). I forego the immediate access to files from both my chroot and ChromeOS environments, but, if I really need this in the future, I can set up a share - probably on a separate device/partition (USB flash drive).