{"id":93709,"date":"2008-06-03T15:19:00","date_gmt":"2008-06-03T15:19:00","guid":{"rendered":"http:\/\/weblogs.madrimasd.org\/\/bioinformatica\/archive\/2008\/06\/03\/93709.aspx"},"modified":"2008-06-03T15:19:00","modified_gmt":"2008-06-03T15:19:00","slug":"cuando-dependes-de-un-programa-antiguo-iii-%c2%bfy-si-el-compilador-no-se-entera-y-te-pone-zancadillas","status":"publish","type":"post","link":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/2008\/06\/03\/93709","title":{"rendered":"Cuando dependes de un programa antiguo (III): \u00bfy si el compilador no se entera, y te pone zancadillas?"},"content":{"rendered":"

Como podeis leer en un post anterior<\/a> sobre c\u00f3mo hacer funcionar Phrap<\/a>, me encontr\u00e9 con el caso curioso de que, en una misma m\u00e1quina de arquitectura IA64<\/a>, los programas de Phrap compilados con GCC<\/a> fallaban con Segmentation Fault<\/i><\/a>, mientras que esos mismos programas compilados con el compilador de pago Intel funcionaban<\/a>. Pues bien, tras estar investigando c\u00f3mo hacer funcionar Phrap de forma nativa en las arquitecturas de 64 bits (x86-64<\/a> e IA64) compil\u00e1ndolo con GCC, me encontr\u00e9 con el meollo del problema: un fallo muy espec\u00edfico al hacer una conversi\u00f3n de tipos en el generador de c\u00f3digo ensamblador del GCC.<\/p>\n


<\/a><\/div>\n

Los programas m\u00e1s antiguos en C usados en bioinform\u00e1tica est\u00e1n escritos en el dialecto C de Kerningan & Ritchie<\/a>, que es muy limitado en cuanto a lo que se pod\u00eda hacer: las funciones devolv\u00edan a lo sumo un entero, no soportaba declaraci\u00f3n de propotipos de funci\u00f3n<\/a> (con lo cu\u00e1l no hab\u00eda validaci\u00f3n de par\u00e1metros), los includes<\/i>, ni macros (no hab\u00eda preprocesador<\/a>) … El c\u00f3digo fuente de Phrap est\u00e1 escrito as\u00ed, pero se nota que ha sido retocado ligeramente a posteriori<\/i>, porque tiene algunos includes<\/i>.
Por ello, como no hab\u00eda NULLs<\/a> (son meros defines<\/i>), en c\u00f3digos escritos en este dialecto su funci\u00f3n es suplida por el 0, y el casting<\/i><\/a> del 0 al tipo de puntero correspondiente. A diferencia de las arquitecturas de 32 bits, en las arquitecturas de 64 bits los punteros de C tienen un tama\u00f1o distintos que los enteros. As\u00ed que si el programa usa el 0 en lugar del NULL como alg\u00fan par\u00e1metro directo para llamar a una funci\u00f3n, y el compilador no sabe que tiene que hacer una conversi\u00f3n impl\u00edtica de tipos (porque no conoce el prototipo<\/a> de la funci\u00f3n a llamar), entonces se produce el desastre<\/b><\/font>.<\/p>\n

Hay dos maneras de solucionar el problema, que implican en ambos casos tener experiencia de programaci\u00f3n en C, e introducir cambios en el c\u00f3digo problem\u00e1tico. La primera es reemplazar todos los usos impl\u00edcitos del 0 como representaci\u00f3n de NULL en las llamadas a funci\u00f3n por (tipo<\/i> *)0, donde tipo<\/i> es el tipo que corresponda. La segunda, que es menos invasiva, consiste precisamente en buscar la declaraci\u00f3n de la funci\u00f3n, y tom\u00e1ndola como base crear el prototipo de la funci\u00f3n. En el caso de Phrap, todo se soluciona a\u00f1adiendo al final del fichero swat.h<\/tt> las l\u00edneas:<\/p>\n

\n
\n
int get_LLR(
\tchar * diffs,
\tchar * orig_qual1,
\tchar * orig_qual2,
\tchar * adj_qual1,
\tchar * adj_qual2,
\tint length1,
\tint start1,
\tint end1,
\tint length2,
\tint start2,
\tint end2,
\tint reverse,
\tSegment * segments1,
\tSegment * segments2,
\tint print_flag,
\tFILE * fp,
\tint q_start1,
\tint q_end1,
\tint q_start2,
\tint q_end2,
\tint ignore_ends
);
<\/pre>\n<\/blockquote>\n<\/blockquote>\n
que corresponden a la declaraci\u00f3n de la funci\u00f3n problem\u00e1tica.<\/p>\n","protected":false},"excerpt":{"rendered":"
Como podeis leer en un post anterior sobre c\u00f3mo hacer funcionar Phrap, me encontr\u00e9 con el caso curioso de que, en una misma m\u00e1quina de arquitectura IA64, los programas de Phrap compilados con GCC fallaban con Segmentation Fault, mientras que esos mismos programas compilados con el compilador de pago Intel funcionaban. Pues bien, tras estar investigando c\u00f3mo hacer funcionar Phrap de forma nativa en las arquitecturas de 64 bits (x86-64 e IA64) compil\u00e1ndolo con GCC, me encontr\u00e9 con el meollo del problema: un fallo muy espec\u00edfico al hacer una conversi\u00f3n de tipos en el generador de c\u00f3digo ensamblador del GCC.\u2026<\/p>\n","protected":false},"author":25,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0},"categories":[187],"tags":[],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":4}},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/posts\/93709"}],"collection":[{"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/comments?post=93709"}],"version-history":[{"count":0,"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/posts\/93709\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/media?parent=93709"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/categories?post=93709"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.madrimasd.org\/blogs\/bioinformatica\/wp-json\/wp\/v2\/tags?post=93709"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}