Meanwhile, this does not happen for all binaries, for example
 - futility - segv
 - crossystem - segv
 - flashrom - prints header then segv 
 - mosys - works fine
 - vpd - works fine
 - xxd - works fine.

Also, if we run the ELF files directly on DUT (not using the wrapper script), it works fine.

In crossystem.c, 
         "Valid parameters:\n", progname, progname, progname, progname);
  for (p = sys_param_list; p->name; p++)
    printf("  %-22s  %s\n", p->name, p->desc);

So it seem to break in looping sys_param_list, so I added more code to check what went wrong:

   printf("Testing: sys_param_list=%p\n", sys_param_list);
  printf("Testing: name=%p\n", sys_param_list->name);
  printf("Testing: desc=%p\n", sys_param_list->desc);
  printf("Testing: name(s)=%s\n", sys_param_list->name);
  printf("Testing: desc(s)=%s\n", sys_param_list->desc);
  for (p = sys_param_list; p->name; p++) {
          printf("Entered loop!\n");
          printf("p=%p!\n", p);
          printf("name/p=%p!\n", p->name);
          printf("desc/p=%p!\n", p->desc);
          printf("name=%s!\n", p->name);
          printf("desc=%s!\n", p->desc);
    printf("  %-22s  %s\n", p->name, p->desc);
  }

And  the output is:

Testing: sys_param_list=0x7a31e73bb240
Testing: name=0x7a31e73b7848
Testing: desc=0x7a31e73b7931
Testing: name(s)=arch
Testing: desc(s)=Platform architecture
Entered loop!
p=0x7a31e73bb240!
name/p=0x5848!
desc/p=0x5931!
Segmentation fault (core dumped)

So even if p & sys_param_list are pointing to same location, and no one was touching *sys_param_list, the name and desc pointer values were changed; and if I try to fetch sys_param_list->name again, the pointer looks good.

Entered loop!
p=0x7de9b814a240!
name/p=0x5888!
desc/p=0x5971!
Testing: name=0x7de9b8146888
Testing: desc=0x7de9b8146971
Segmentation fault (core dumped)

The values in memory seems good, so I really can't figure out why p->name returns wrong pointer :(

I can reproduce even in chroot, no need to run on DUT.

However, on gLinux, it's interesting that
 - Inside chroot, "bin/crossystem.elf -h " (skip wrapper) won't crash.
 - Inside chroot, "bin/crossystem -h" (with wrapper) will crash with same result
 - Outside chroot, bin/crossystem -h" (without wrapper) will crash
 - Outside chroot, bin/crossystem.elf -h" (without wrapper) WILL STILL crash

This is really interesting...

#0  0x00007ffff7b5fd41 in __strcasecmp_l_avx () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000555555558c06 in VbGetArchPropertyString ()
#2  0x00005555555564e3 in VbGetSystemPropertyString ()
#3  0x0000555555555b5c in PrintAllParams ()
#4  0x00007ffff7a5a2b1 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x0000555555555739 in _start ()

Meanwhile, crossystem built for chroot (sudo emerge vboot_reference) does not have such problem.
I see this only if it's compiled under 'eve' profile (emerge-eve vboot_reference).

executing any .elf file directly is not supported.  don't bother trying to debug that.  you're going to be mixing glibc versions.

what board are you testing against ?  i ran lddtree by hand with board=link and the programs are running fine for me.

My DUT is board=eve.

i still can't reproduce this.  i ran build_packages --board=eve then did:
  mkdir /tmp/foo
  /build/eve/usr/sbin/chromeos-firmwareupdate --sb_extract /tmp/foo
  /tmp/foo/bin/crossystem --help
  /tmp/foo/bin/futility --help
  /tmp/foo/bin/vpd --help

mosys aborts, but that's to be expected as it tries to assert some sandboxing logic that only works as root.

then i repeated using the prebuilts from the eve-paladin and those work fine too.
  gsutil cp gs://chromeos-prebuilt/board/eve/paladin-R71-11042.0.0-rc2/packages/chromeos-base/chromeos-firmware-eve-0.0.1-r167.tbz2 ./
  tar xvf chromeos-firmware-eve-0.0.1-r167.tbz2 ./usr/sbin/chromeos-firmwareupdate
  ./usr/sbin/chromeos-firmwareupdate --sb_extract /tmp/foo

so at this point, this seems to be a bug that only exists on your system ...

Hmmm, that's really weird. I tried again and that for every boards (poppy, eve, ...) it's all the same.

And when I copy the files to DUT, it'll all crash.

Really can't figure out why, but it seems working fine on other's computer.

Probably you're right, it's a problem only on my system...

Will archive this in case if some people also see segv.

As a record:

I deleted whole chroot and tried to rebuild.
Now my lddtree copied files are working happily.

If any developers see same issue, please re-create your chroot. update_chroot won't help. You have to re-create from scratch.

For the record:

I think this is probably due to having toolchain changed between gcc/clang in chroot created long ago, and then caused some incompatible issues inside libc or other libraries.

So if anyone sees this, re-create your chroot.