Static binary not working from AMD nodes

[telatin]

Hello Brent! I tried compiling a static binary with your docker solution, and it doesn't work from the AMD nodes in the cluster I use. (i.e. the help screen is displayed, but as soon as I try parsing a BAM file I get SIGILL: Illegal operation.).

Since I don't know if this is unavoidable or just remoing some optimizations could make the binary working also with old AMD processors I put a note here (worse case scenario this can be mentioned in the README).

Thanks again, Andrea

PS: here the /proc/cpuinfo bit:

processor       : 31
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 9
model name      : AMD Opteron(tm) Processor 6134
stepping        : 1
microcode       : 0x10000d9
cpu MHz         : 1400.000
cache size      : 512 KB
physical id     : 3
siblings        : 8
core id         : 3
cpu cores       : 8
apicid          : 71
initial apicid  : 55
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc art rep_good nopl nonstop_tsc extd_apicid amd_dcm pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate retpoline_amd ibp_disable vmmcall npt lbrv svm_lock nrip_save pausefilter
bogomips        : 4600.48
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

[brentp]

hmm. I'm not sure how to debug this.

can you try building with the -x flag to hts_nim_static_builder? that turns on debug build so we might bet a bit more information.

I'll see if I can find some old nodes to test on as well.

[telatin]

Nice, didn't notice that flag:

Traceback (most recent call last)
/local/src/covtobed2.nim(254) covtobed2
/local/src/covtobed2.nim(229) main
/root/.nimble/pkgs/hts-0.3.11/hts/bam.nim(373) open
SIGILL: Illegal operation.

[brentp]

is the file local? can you show the code in cov2bed2?

[brentp]

you may also be able to run your binary under gdb to get a better backtrace.

[telatin]

I'm sorry, gdb seems too complicated for me. cov2bed2 is basically an empty script to read a BAM file, as I never tried htslib in the past (I was used to libbamtools). I compiled the hts_nim_tools from your repository using again the static builder.

I compiled (as I did in the first example) from an Ubuntu VM and the path was /local/giovanni/..., that pops out in the traceback:

./hts_nim_static_builder -x -n hts_nim_tools.nimble -s src/hts_nim_tools.nim 

The command hts_nim_tools bam-filter is_proper_pair ./test_output/mini.mapping.bam works fine from any intel node, and again fails in the Opteron ones. This is not necessarily a terrible thing, but if it's easy to update the builder this would give a broader use to the compiled tools...

~/tmp/hts_nim_tools bam-filter is_proper_pair ./test_output/mini.mapping.bam

Traceback (most recent call last)
/local/giovanni/hts-nim-tools/src/hts_nim_tools.nim(50) hts_nim_tools
/local/giovanni/hts-nim-tools/src/hts_nim_tools.nim(47) main
/local/giovanni/hts-nim-tools/src/bam_filter.nim(53) bam_filter
/root/.nimble/pkgs/hts-0.3.4/hts/bam.nim(337) open
SIGILL: Illegal operation.

[brentp]

I'd like to fix this, but I'm not sure how. :(