todas tipos programacion las generado funciones flotante excepción ejemplos coma abortado c linux gcc elf sigfpe

las - tipos de funciones en programacion



Excepción de coma flotante(SIGFPE) en ''int main(){return(0);}'' (2)

Como funciona en el ATOM pero no en el Celeron antiguo, creo que el problema podría ser con un código de generación de optimización del compilador que el Celeron no puede ejecutar. Intenta compilar con la bandera -O0. Además, sugeriría agregar -march = i686 para indicar explícitamente la arquitectura. Además, para ayudar a aislar el problema, también sugiero deshabilitar el enlace al tiempo de ejecución de C ++ y JAVA.

¿Construyó este programa de prueba una vez y lo ejecutó en cada dispositivo, o construyó un ejecutable diferente para cada dispositivo? Si está construyendo un ejecutable, puede tener versiones diferentes de libc, libstdc ++ en los dos dispositivos o en los dispositivos en comparación con su máquina de compilación.

Estoy intentando construir un programa C simple para dos entornos de Linux diferentes. En un dispositivo, el programa funciona bien, en el otro dispositivo, el programa genera una excepción de coma flotante. El programa no hace más que devolver 0 desde main, lo que me lleva a creer que hay alguna incompatibilidad con el código de inicio, ¿tal vez ABI?

El programa está compilado con gcc con las siguientes especificaciones de compilación:

Usando las especificaciones incorporadas. Objetivo: i386-redhat-linux Configurado con: ../configure --prefix = / usr --mandir = / usr / share / man --infodir = / usr / share / info --enable-shared --enable-threads = posix --enable-checking = release --with-system-zlib --enable -__ cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages ​​= c, c ++, objc, obj-c ++ , java, fortran, ada --enable-java-awt = gtk --disable-dssi --disable-plugin --with-java-home = / usr / lib / jvm / java-1.4.2-gcj-1.4. 2.0 / jre --with-cpu = genérico --host = i386-redhat-linux Modelo de subproceso: posix gcc versión 4.1.2 20080704 (Red Hat 4.1.2-52)

La fuente del programa es la siguiente:

int main() { return(0); }

En el dispositivo Celeron este programa genera lo siguiente bajo GDB:

[root@n00200C30AA2F jrn]# /jrn/gdb fail GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) (gdb) run Starting program: /jrn/fail Program received signal SIGFPE, Arithmetic exception. 0x40001cce in ?? () (gdb) bt #0 0x40001cce in ?? () #1 0x4000c6b0 in ?? () #2 0x40000cb5 in ?? ()

A continuación se detallan los detalles que puedo pensar para recopilar y ayudar a descubrir lo que está sucediendo:

CELERON: ( fails on this device ) 2.6.8 #21 Mon Oct 1 11:41:47 PDT 2007 i686 i686 i386 GNU/Linux ============ [root@n00200C30AA2F proc]# cat cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Celeron(R) M processor 600MHz stepping : 5 cpu MHz : 599.925 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe bogomips : 1179.64 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). Compiled on a Linux 2.4.20 system on 2003-03-13. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk ATOM: ( works fine on this device ) 2.6.35 #25 SMP Mon Mar 12 09:02:45 PDT 2012 i686 i686 i386 GNU/Linux ========== [root@n00E04B36ECE5 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Genuine Intel(R) CPU N270 @ 1.60GHz stepping : 2 cpu MHz : 1599.874 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm bogomips : 3199.74 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: GNU C Library stable release version 2.5, by Roland McGrath et al. Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44). Compiled on a Linux 2.6.9 system on 2009-09-02. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson GNU libio by Per Bothner NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio Thread-local storage support included.

¿Qué puedo hacer para determinar qué está causando este problema? ¿Qué hay de tratar de vincular estáticamente contra una determinada versión de libc?

Después de que ocurra la falla bajo GDB, ejecuto:

(gdb) x/1i $eip 0x40001cce: divl 0x164(%ecx)

(gdb) info reg eax 0x6c994f 7117135 ecx 0x40012858 1073817688 edx 0x0 0 ebx 0x40012680 1073817216 esp 0xbffff740 0xbffff740 ebp 0xbffff898 0xbffff898 esi 0x8049580 134518144 edi 0x400125cc 1073817036 eip 0x40001cce 0x40001cce eflags 0x10246 66118 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x0 0 (gdb) x/1wx 0x164+$ecx 0x400129bc: 0x00000000 (gdb)

Según la ayuda que he recibido, parece que, por algún motivo, el código de inicio de libc se divide por 0.

La pregunta ahora es, ¿qué está causando este obviamente mal comportamiento? Algo debe ser incompatible con otra cosa?

Salida de ensamblaje:

[jrn@localhost ~]$ more fail.s .file "fail.c" .text .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx movl $0, %eax popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .ident "GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-52)" .section .note.GNU-stack,"",@progbits

Esto va a sonar como un tiro muy largo ... ¿pero puedes intentar lo siguiente?

$ readelf -a fail

y busque una etiqueta dinámica GNU_HASH? Supongo que el binario usa GNU_HASH , y tu ld.so es demasiado viejo para entenderlo. El soporte para la sección hash de GNU se agregó a glibc alrededor de 2006, y las distribuciones principales comenzaron a ser solo hash de GNU alrededor de 2007 o 2008. Su glibc de Centrino es de 2003 , anterior al hashing de GNU.

Si ld.so no entiende el hash de GNU, intentará usar la antigua sección hash ELF, que está vacía. En particular, sospecho que su bloqueo se está produciendo en esta línea en elf/do-lookup.h :

for (symidx = map->l_buckets[hash % map->l_nbuckets];

Como es probable que el enlazador no comprenda los hashes de GNU, l_nbuckets sería 0, lo que da como resultado el bloqueo. Tenga en cuenta que el map es una estructura grande con alrededor de 100 elementos de estructura, y l_nbuckets está alrededor del miembro 90 de la estructura en ld.so más ld.so ( 0x164 = 4*89 , por lo que en ld.so más ld.so probablemente sea este miembro).

Para ver si este es el problema de manera concluyente , compilar con -Wl,--hash-style=sysv o -Wl,--hash-style=both y ver si el bloqueo desaparece.