imp: Problemas con .include

Cuando agregamos los .include en la Prueba de la Parte B nos salta el siguiente error de compilación:

UNDEFINED SYMBOLS
variable
tabla
rutint
PruebaParteB.o:F:\\IMP\\PRACTICA3\\PARTEB/hexa7seg.s:10: undefined reference to `variable'
PruebaParteB.o:F:\\IMP\\PRACTICA3\\PARTEB/hexa7seg.s:12: undefined reference to `tabla'
PruebaParteB.o:F:\\IMP\\PRACTICA3\\PARTEB/hexa7seg.s:19: undefined reference to `rutint'
PruebaParteB.o:F:\\IMP\\PRACTICA3\\PARTEB/hexa7seg.s:20: undefined reference to `tabla'
C:\paquetes\z80-tools\binutils-z80\z80-coff-objdump: 'PruebaParteB': No such file

Que puede ser?

Re: Problemas con .include

de Leonardo Etcheverry - miércoles, 1 de junio de 2016, 17:11

Rodrigo,

Verifiquen que no se les escapó un ".end" en alguno de los archivos que estan incluyendo (y otros archivos que puedan ser incluídos por los anteriores, recursivamente).

Cuando el ensamblador encuentra un .end, deja de procesar el texto que venga más adelante.

Saludos,
leo.

Re: Problemas con .include

de Rodrigo Nicolas Fenocchi Arroyo - miércoles, 1 de junio de 2016, 18:20

Le borramos los .end que tenian las subrutinas llamadas y ahora compila bien, pero cuando ejecutamos el programa, cuando presionamos Button1 nos dice: "Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000206 in ?? <>"

Sin embargo, si no usamos el .include funciona con normalidad. Esta bien dejarlo asi?

Re: Problemas con .include

de Leonardo Etcheverry - miércoles, 1 de junio de 2016, 18:45

Bueno, el buen funcionamiento de su código debería ser independiente de si usan o no include. La única diferencia que se me ocurre podría aparecer, comparando una versión sin include y una con includes, es como les quedan código y datos organizados en memoria.

Puede ser que tengan algún problema en su código, que se manifiesta o no de acuerdo a como queden organizadas las rutinas y datos en memoria. Yo les recomendaría analizar e intentar enteder cual es el origen del problema. (Que no se manifieste al no usar include, no necesariamente quiere decir que la causa del problema no exista en primer lugar.)

Para empezar, empiecen por comparar los listados que les genera el compilador donde se muestran donde terminan las cosas en memoria.

Finalmente,
Trace/breakpoint trap. 0x00000206 in ?? <>" en la dirección 0x206, generalmente se da cuando el flujo de ejecución del programa (el PC) se les fue
para cualquier lado. Puede deberse a muchas razones:

- se corrompieron los datos en el stack (dirección de retorno).
- los datos de la tabla de interrupciones no son coherentes
- el procesador intentó ejecutar datos
- etc.