On Linux, the getcwd system call returns /home/foo/dir1 in your scenario.

#include <unistd.h>
#include <stdio.h>
#include <limits.h>

int main() {
   char cwd[PATH_MAX];
   if (getcwd(cwd, sizeof(cwd)) == NULL) {
      perror("getcwd");
      return 1;
   }

   printf("Current working dir: %s\n", cwd);

   return 0;
}
[download]

[~/sym1]$ gcc -Wall -Wextra -pedantic a.c -o a && ./a
Current working dir: /home/ikegami/dir1
[download]

---

It's not that bash sets the child's CWD differently than its own; /proc shows that bash's CWD is also resolved.

[~/sym1]$ readlink /proc/$$/cwd
/home/ikegami/dir1
[download]

---

In fact, the system call to get the CWD returns the resolved link even if you explicitly set the CWD to the link.

#include <unistd.h>
#include <stdio.h>
#include <limits.h>

int main() {
   if (chdir("/home/ikegami/sym1")) {
      perror("chdir");
      return 1;
   }

   char cwd[PATH_MAX];
   if (getcwd(cwd, sizeof(cwd)) == NULL) {
      perror("getcwd");
      return 1;
   }

   printf("Current working dir: %s\n", cwd);

   return 0;
}
[download]

[~/sym1]$ gcc -Wall -Wextra -pedantic a.c -o a && ./a
Current working dir: /home/ikegami/dir1
[download]

---

What this means is that in no way is the process's CWD /home/ikegami/sym1 as you think. So short of trusting $ENV{PWD} to be accurate, it's simply impossible to get /home/ikegami/sym1 from the system since that's not the process's CWD.

use 5.010;
use Path::Tiny qw( path );
say path($0)->absolute($ENV{PWD});
[download]

[~/sym1]$ perl a.pl
/home/ikegami/sym1/a.pl
[download]

Do note that this is entirely insecure.

A setuid script that relies on unresolved links in $0 is insecure.
A setuid script that relies on $ENV{PWD} is insecure.