stringtranslate.com

Auto-reubicación

En programación informática , un programa autorreubicable es un programa que reubica sus propias instrucciones y datos dependientes de la dirección cuando se ejecuta y, por lo tanto, es capaz de cargarse en la memoria en cualquier dirección. [1] [2] En muchos casos, el código autorreubicable también es una forma de código automodificable .

Descripción general

La autorreubicación es similar al proceso de reubicación empleado por el enlazador - cargador cuando un programa se copia desde un almacenamiento externo a la memoria principal; la diferencia es que es el programa cargado en sí mismo, en lugar del cargador en el sistema operativo o shell , el que realiza la reubicación.

Una forma de autorreubicación ocurre cuando un programa copia el código de sus instrucciones de una secuencia de ubicaciones a otra secuencia de ubicaciones dentro de la memoria principal de una sola computadora y luego transfiere el control del procesador de las instrucciones que se encuentran en las ubicaciones de origen de la memoria a las instrucciones que se encuentran en las ubicaciones de destino de la memoria. De esta manera, los datos que procesa el algoritmo del programa son la secuencia de bytes que define el programa.

La autorreubicación estática generalmente ocurre en el momento de la carga (después de que el sistema operativo ha cargado el software y le ha pasado el control, pero aún antes de que haya terminado su inicialización), a veces también cuando se cambia la configuración del programa en una etapa posterior durante el tiempo de ejecución . [3] [4]

Ejemplos

Cargadores de arranque

Como ejemplo, la autorreubicación se emplea a menudo en las primeras etapas del arranque de sistemas operativos en arquitecturas como las compatibles con IBM PC , donde los cargadores de arranque en cadena de nivel inferior (como el registro de arranque maestro (MBR), el registro de arranque de volumen (VBR) y las etapas de arranque iniciales de sistemas operativos como DOS ) se mueven fuera de lugar para cargar la siguiente etapa en la memoria.

Extensiones CP/M

En CP/M , la herramienta de depuración dinámica (DDT) del depurador se reubica dinámicamente en la parte superior de la memoria disponible a través de la reubicación del límite de página para maximizar el área de programa transitorio (TPA) para que se ejecuten los programas. [5] [6]

En 1988, el procesador de línea de comandos alternativo ZCPR 3.4 para el Z-System introdujo los llamados programas tipo 4 , que también eran auto-reubicables a través de un stub incorporado. [7] [8] [9] [10] [11]

Controladores DOS x86

En DOS , la auto-reubicación a veces también es utilizada por controladores más avanzados y extensiones residentes del sistema (RSXs) o programas residentes de terminación y permanencia (TSRs) cargándose a sí mismos "en lo alto" en la memoria superior de manera más efectiva que lo posible para cargadores "altos" provistos externamente (como LOADHIGH / HILOAD , INSTALLHIGH / HIINSTALL o DEVICEHIGH / HIDEVICE etc. [12] desde DOS 5) para maximizar la memoria disponible para aplicaciones. Esto se debe al hecho de que el sistema operativo no tiene conocimiento del funcionamiento interno de un controlador que se va a cargar y, por lo tanto, tiene que cargarlo en un área de memoria libre lo suficientemente grande como para contener todo el controlador como un bloque que incluye su código de inicialización, incluso si este se liberara después de la inicialización. Para los TSR, el sistema operativo también tiene que asignar un Prefijo de Segmento de Programa (PSP) y un segmento de entorno . [13] Esto puede hacer que el controlador no se cargue en el área de memoria libre más adecuada o incluso evitar que se cargue en lo alto. En contraste con esto, un controlador auto-reubicable puede cargarse en cualquier lugar (incluso en la memoria convencional ) y luego reubicar solo su porción residente (normalmente mucho más pequeña) en un área de memoria libre adecuada en la memoria superior. Además, los TSR auto-reubicables avanzados (incluso si ya están cargados en la memoria superior por el sistema operativo) pueden reubicarse en la mayor parte de su propio segmento PSP y buffer de línea de comandos y liberar su segmento de entorno para reducir aún más la huella de memoria resultante y evitar la fragmentación . [14] Algunos TSR auto-reubicables también pueden cambiar dinámicamente su "naturaleza" y transformarse en controladores de dispositivos incluso si se cargaron originalmente como TSR, por lo que normalmente también liberan algo de memoria. [4] Finalmente, es técnicamente imposible para un cargador externo reubicar los controladores en la memoria expandida (EMS), el área de memoria alta (HMA) o la memoria extendida (a través de DPMS o CLOAKING ), porque estos métodos requieren que pequeños stubs específicos del controlador permanezcan en la memoria convencional o superior para coordinar el acceso al área de destino de la reubicación, [15] [nb 1] [nb 2] y en el caso de los controladores de dispositivos también porque el encabezado del controlador siempre debe permanecer en el primer megabyte. [15] [13]Para lograr esto, los conductores deben estar especialmente diseñados para apoyar la auto-reubicación en estas áreas. [15]

Algunos controladores DOS avanzados también contienen un controlador de dispositivo (que se cargaría en el desplazamiento +0000h por el sistema operativo) y TSR (cargado en el desplazamiento +0100h) que comparten una porción de código común internamente como binario fat . [13] Si el código compartido no está diseñado para ser independiente de la posición , requiere alguna forma de reparación de dirección interna similar a lo que de otro modo ya habría llevado a cabo un cargador de reubicación ; esto es similar a la etapa de reparación de la auto-reubicación pero con el código ya cargado en la ubicación de destino por el cargador del sistema operativo (en lugar de hacerlo el propio controlador).

Programas IBM DOS/360 y OS/360

IBM DOS/360 no tenía la capacidad de reubicar programas durante la carga. A veces se mantenían múltiples versiones de un programa, cada una construida para una dirección de carga diferente ( partición ). Una clase especial de programas, llamados programas auto-reubicables, fueron codificados para reubicarse a sí mismos después de la carga. [16] IBM OS/360 reubicaba los programas ejecutables cuando se cargaban en la memoria. Solo se requería una copia del programa, pero una vez cargado, el programa no podía ser movido (el llamado código independiente de la posición de un solo uso ).

Otros ejemplos

Como ejemplo extremo de auto-reubicación (muchas veces), también llamada auto-reubicación dinámica, es posible construir un programa de computadora de modo que no permanezca en una dirección fija en la memoria, incluso mientras se ejecuta, como por ejemplo se usa en pruebas de memoria de gusanos . [17] [18] [19] [20] El gusano Apple también es un auto-reubicador dinámico. [21]

Véase también

Notas

  1. ^ Una excepción al requisito de un stub es cuando la memoria expandida se convierte en memoria superior permanente por el administrador de memoria a través de EMSUMB y, por lo tanto, se accede a ella efectivamente como memoria superior , no a través de EMS .
  2. ^ Hay dos excepciones al requisito de stub para que un controlador se cargue en la HMA : un stub no es necesario cuando la memoria alta está habilitada permanentemente en máquinas sin lógica de puerta A20 , sin embargo, como esta condición no se cumple en general, los controladores DOS genéricos no pueden aprovecharla (a menos que prueben explícitamente esta condición de antemano). De lo contrario, un stub tampoco es necesario bajo DR DOS 6.0 y superior, cuando las extensiones del sistema residente (como SHARE y NLSFUNC ) solo enganchan la interrupción multiplex INT 2Fh, porque luego pueden utilizar una interfaz de puerta trasera para engancharse a la cadena de interrupciones en el espacio del núcleo para que el manejador de puerta A20 del núcleo proporcione la funcionalidad del stub. [a] Aún así, el controlador tiene que realizar una auto-reubicación para funcionar correctamente en la HMA.

Referencias

  1. ^ Dhamdhere, Dhananjay M. (1999). Programación de Sistemas y Sistemas Operativos. Educación. Nueva Delhi, India: Tata McGraw-Hill . pag. 232.ISBN​ 0-07-463579-4. ISBN 978-0-07-463579-7 . Archivado desde el original el 1 de febrero de 2020 . Consultado el 8 de noviembre de 2011 . (658 páginas)
  2. ^ Dhamdhere, Dhananjay M. (2006). Sistemas operativos: un enfoque basado en conceptos. Educación. Nueva Delhi, India: Tata McGraw-Hill . pag. 231.ISBN​ 0-07-061194-7. ISBN 978-0-07-061194-8 . Archivado desde el original el 20 de febrero de 2020 . Consultado el 20 de febrero de 2020 . (799 páginas)
  3. ^ Paul, Matthias R.; Frinke, Axel C. (13 de octubre de 1997) [1991], FreeKEYB - Controlador de consola y teclado DOS mejorado (Manual del usuario) (6.5 ed.)[1] (NB. FreeKEYB es un controlador configurable dinámicamente basado en Unicode que admite la mayoría de los diseños de teclado , páginas de códigos y códigos de países . Utilizando un ensamblador de macros listo para usar, así como un marco de herramientas de análisis automático de preprocesamiento y posprocesamiento para generar metadatos de dependencia y transformación de código para ser incorporados en el archivo ejecutable junto con el código binario y un cargador de autodescarte, relajación y reubicación , el controlador admite ser cargado e instalado de diversas formas como TSR o controlador de dispositivo e implementa técnicas avanzadas de auto-reubicación (incluyendo en memoria DOS normal , UMB , memoria de video sin usar o memoria sin procesar, también utilizando sobrecarga de prefijo de segmento de programa y recombinación de segmento de entorno ) y eliminación de código muerto dinámico granular a nivel de byte en tiempo de carga , así como código de auto-modificación y reconfigurabilidad en tiempo de ejecución para minimizar su huella de memoria dependiendo del hardware, sistema operativo y configuración del controlador, así como el conjunto de características y configuración regional seleccionados).
  4. ^ ab Paul, Matthias R.; Frinke, Axel C. (16 de enero de 2006), FreeKEYB - Controlador de consola y teclado DOS internacional avanzado (Manual del usuario) (7.ª edición (preliminar)).
  5. ^ Kildall, Gary Arlen (febrero de 1978) [1976]. "Una técnica sencilla para la reubicación estática de código de máquina absoluto". Revista de calistenia y ortodoncia informática del Dr. Dobb . 3 (2). People's Computer Company : 10-13 (66-69). ISBN 0-8104-5490-4. #22 ark:/13960/t8hf1g21p . Consultado el 19 de agosto de 2017 .[2][3][4]. Presentado originalmente en: Kildall, Gary Arlen (1977) [22–24 de noviembre de 1976]. "Una técnica simple para la reubicación estática de código de máquina absoluto". Escrito en Naval Postgraduate School , Monterey, California, EE. UU. En Titus, Harold A. (ed.). Registro de la conferencia: Décima conferencia anual de Asilomar sobre circuitos, sistemas y computadoras: artículos presentados del 22 al 24 de noviembre de 1976. Asilomar Hotel and Conference Grounds, Pacific Grove, California, EE. UU.: Western Periodicals Company. págs. 420–424. ISSN  1058-6393 . Consultado el 6 de diciembre de 2021 .(609 páginas). (Este método de "cambio de tamaño", llamado reubicación de límites de página , se podía aplicar estáticamente a una imagen de disco CP/M-80 usando MOVCPM  [pl] para maximizar el TPA para que se ejecutaran los programas. También lo utilizó dinámicamente el depurador CP/M Dynamic Debugging Tool (DDT) para reubicarse en una memoria superior. El mismo enfoque fue desarrollado independientemente por Bruce H. Van Natta de IMS Associates para producir código PL/M reubicable . Como reubicación de límites de párrafo , otra variante de este método fue utilizada más tarde por los TSR auto-reubicantes HMA dinámicos como KEYB , SHARE y NLSFUNC bajo DR DOS 6.0 y superiores. Un método de reubicación de desplazamiento granular a nivel de bytes mucho más sofisticado y basado en un enfoque algo similar fue concebido e implementado independientemente por Matthias R. Paul y Axel C. Frinke para su eliminación dinámica de código muerto para minimizar dinámicamente la huella de tiempo de ejecución de los controladores residentes y los TSR (como FreeKEYB).)
  6. ^ Huitt, Robert; Eubanks, Gordon ; Rolander, Thomas "Tom" Alan ; Laws, David; Michel, Howard E.; Halla, Brian; Wharton, John Harrison ; Berg, Brian; Su, Weilian; Kildall, Scott ; Kampe, Bill (25 de abril de 2014). Laws, David (ed.). "Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication" (PDF) (transcripción del vídeo). Pacific Grove, California, EE. UU.: Computer History Museum . Número de referencia del CHM: X7170.2014. Archivado (PDF) desde el original el 27 de diciembre de 2014 . Consultado el 19 de enero de 2020 . […] Laws: […] " reubicación dinámica " del sistema operativo. ¿Puede decirnos qué es eso y por qué era importante? […] Eubanks : […] lo que hizo Gary […] fue […] alucinante. […] Recuerdo el día en la escuela que entró de golpe al laboratorio y dijo: “He descubierto cómo reubicar” . Aprovechó el hecho de que el único byte siempre iba a ser el byte de orden superior . Y así creó un mapa de bits . […] No importaba cuánta memoria tuviera la computadora, el sistema operativo siempre se podía mover a la memoria superior. Por lo tanto, se podía comercializar esto […] en máquinas con diferentes cantidades de memoria. […] No se podía vender un CP/M de 64K y un CP/M de 47K. Sería ridículo tener una compilación difícil en las direcciones. Así que Gary se dio cuenta de esto una noche, probablemente en mitad de la noche pensando en algo de codificación, y esto realmente hizo que CP/M fuera posible comercializar. Realmente creo que sin esa reubicación habría sido un problema muy difícil. Hacer que la gente lo compre les parecería complicado, y si añadías más memoria tendrías que conseguir un sistema operativo diferente. […] Intel […] tenía los bytes invertidos , ¿no?, para las direcciones de memoria. Pero siempre estaban en el mismo lugar, por lo que se podían reubicar en un límite de 256 bytes , para ser precisos. Por lo tanto, siempre se podía reubicar con solo un mapa de bits de dónde estaban esos […] Leyes: Sin duda, la explicación más elocuente que he tenido sobre la reubicación dinámica […][5][6] (33 páginas)
  7. ^ Sage, Jay (mayo-junio de 1988). Carlson, Art (ed.). "ZCPR 3.4 - Programas de tipo 4". The Computer Journal (TCJ) - Programación, soporte al usuario, aplicaciones . ZCPR3 Corner (32). Columbia Falls, Montana, EE. UU.: 10-17. ISSN  0748-9331. ark:/13960/t1wd4v943 . Consultado el 29 de noviembre de 2021 .[7][8]
  8. ^ Mitchell, Bridger (julio-agosto de 1988). Carlson, Art (ed.). "Z3PLUS y reubicación: información sobre ZCPR3PLUS y cómo escribir código Z80 autoreubicable". The Computer Journal (TCJ): programación, asistencia al usuario, aplicaciones . Advanced CP/M (33). Columbia Falls, Montana, EE. UU.: 9-15. ISSN  0748-9331. ark:/13960/t36121780 . Consultado el 9 de febrero de 2020 .[9][10]
  9. ^ Sage, Jay (septiembre-octubre de 1988). Carlson, Art (ed.). "Más sobre código reubicable, archivos PRL, ZCPR34 y programas de tipo 4". The Computer Journal (TCJ) - Programación, soporte al usuario, aplicaciones . ZCPR3 Corner (34). Columbia Falls, Montana, EE. UU.: 20-25. ISSN  0748-9331. ark:/13960/t0ks7pc39 . Consultado el 9 de febrero de 2020 .[11][12][13]
  10. ^ Sage, Jay (enero-febrero de 1992). Carlson, Art; McEwen, Chris (eds.). "Diez años de ZCPR". The Computer Journal (TCJ) - Programación, soporte al usuario, aplicaciones . Z-System Corner (54). S. Plainfield, Nueva Jersey, EE. UU.: Socrates Press: 3–7. ISSN  0748-9331. ark:/13960/t89g6n689 . Consultado el 29 de noviembre de 2021 .[14][15][16]
  11. ^ Sage, Jay (mayo-junio de 1992) [marzo-junio de 1992]. Carlson, Art; McEwen, Chris (eds.). "Programas de tipo 3 y tipo 4". The Computer Journal (TCJ) - Programación, soporte al usuario, aplicaciones . Z-System Corner - Algunas nuevas aplicaciones de programas de tipo 4 (55). S. Plainfield, Nueva Jersey, EE. UU.: Socrates Press: 13-19. ISSN  0748-9331. ark:/13960/t4dn54d22 . Consultado el 29 de noviembre de 2021 .[17][18]
  12. ^ "Capítulo 10: Administración de la memoria". Guía del usuario de Caldera DR-DOS 7.02 . Caldera, Inc. 1998 [1993, 1997]. Archivado desde el original el 2017-08-30 . Consultado el 2017-08-30 .
  13. ^ abc Paul, Matthias R. (6 de abril de 2002). "Re: [fd-dev] ANUNCIO: CuteMouse 2.0 alpha 1". freedos-dev . Archivado desde el original el 7 de febrero de 2020 . Consultado el 7 de febrero de 2020 . […] Agregue un encabezado de controlador de dispositivo SYS al controlador, de modo que CTMOUSE pueda ser a la vez un TSR normal y un controlador de dispositivo, similar a nuestro controlador de teclado avanzado FreeKEYB. […] Esto no es realmente necesario en DR DOS porque INSTALL = es compatible desde DR DOS 3.41+ y DR DOS conserva el orden de las directivas [D]CONFIG.SYS […] pero mejoraría […] la flexibilidad en los sistemas MS-DOS / PC DOS , que […] siempre ejecutan las directivas DEVICE = antes de cualquier instrucción INSTALL=, independientemente de su orden en el archivo. […] El software puede requerir que el controlador del mouse esté presente como un controlador de dispositivo, ya que los controladores de mouse siempre han sido controladores de dispositivo en los viejos tiempos. Estos controladores de mouse han tenido nombres de controlador de dispositivo específicos según el protocolo que usaron (" PC$MOUSE " para el modo de sistemas de mouse , por ejemplo), y algún software puede buscar estos controladores para averiguar el tipo correcto de mouse que se usará. […] Otra ventaja sería que los controladores de dispositivo generalmente consumen menos memoria (sin entorno , sin PSP ) […] Básicamente, es un encabezado de archivo complicado, un código diferente para analizar la línea de comando, un punto de entrada y una línea de salida diferentes, y algo de magia de segmento para superar la diferencia ORG 0 / ORG 100h. La carga automática de un controlador de dispositivo es un poco más complicada, ya que debe dejar el encabezado del controlador donde está y solo reubicar el resto del controlador […]
  14. ^ Paul, Matthias R. (18 de agosto de 2001). "Re: [fd-dev] Acerca de GRAFTABL y DISPLAY.SYS (antes: Cambiar páginas de códigos en FreeDOS)". freedos-dev . Archivado desde el original el 4 de septiembre de 2017 . Consultado el 4 de septiembre de 2017 . […] Al menos el MS-DOS 6.0 + GRAFTABL se reubica sobre partes de su segmento PSP (desplazamiento +60h y hacia arriba) para minimizar su tamaño residente. […](NB. Una versión GRAFTABL 2.00+ posterior a DR-DOS 7.03 también admite la reubicación automática dinámica).
  15. ^abc Paul, Matthias R. (2002-02-02). "Treiber dynamisch nachladen" [Carga de controladores dinámicamente] (en alemán). Grupo de noticias : de.comp.os.msdos. Archivado desde el original el 2017-09-09 . Consultado el 2017-07-02 .(NB. Proporciona una descripción general de los métodos de alta carga en DOS, incluido el uso de comandos LOADHIGH , etc. y métodos de reubicación automática en UMB utilizando la API XMSUMB . También analiza métodos más sofisticados necesarios para que los TSR se reubiquen en el HMA utilizando la reubicación de desplazamiento dentro del segmento ).
  16. ^ Boothe Management Systems (1972-11-01). "Rendimiento: ¿está obteniendo todo lo que se merece? - DOSRELO". Computerworld - The Newsweekly For The Computer Community (anuncio). Vol. VI, no. 44. San Francisco, California, EE. UU.: Computerworld, Inc. p. 9. Archivado desde el original el 2020-02-06 . Consultado el 2020-02-07 . […] DOSRELO proporciona un método para hacer que los programas de problemas de DOS se reubiquen automáticamente. DOSRELO logra la capacidad de reubicación automática para todos los programas, independientemente del lenguaje, agregando lógica de punto de entrada al código objeto del programa antes de que el Editor de vínculos lo catalogue en la Biblioteca de imágenes del núcleo . […]
  17. ^ La prueba de memoria del gusano (PDF) . Gráfico vectorial . 2015-10-21. Archivado (PDF) desde el original el 2019-05-15 . Consultado el 2021-12-13 .(3 páginas) (NB. De un manual de servicio de Vector Graphic 3 ).
  18. ^ Wilkinson, William "Bill" Albert (2003) [1996, 1984]. "El gusano H89: prueba de memoria del H89". Página de Bill Wilkinson en Heath Company . Archivado desde el original el 13 de diciembre de 2021. Consultado el 13 de diciembre de 2021. […] Además de buscar una instrucción, el Z80 utiliza la mitad del ciclo para refrescar la RAM dinámica . […] dado que el Z80 debe dedicar la mitad de cada ciclo de búsqueda de instrucciones a realizar otras tareas, no tiene tanto tiempo para buscar un byte de instrucción como para buscar un byte de datos. Si uno de los chips de RAM en la ubicación de memoria a la que se accede es un poco lento, el Z80 puede obtener el patrón de bits incorrecto cuando busca una instrucción, pero obtener el correcto cuando lee datos. […] la prueba de memoria incorporada no detectará este tipo de problema […] es estrictamente una prueba de lectura/escritura de datos. Durante la prueba, todas las instrucciones se obtienen de la ROM , no de la RAM […] lo que da como resultado que el H89 pase la prueba de memoria pero siga funcionando de forma errática en algunos programas. […] Este es un programa que prueba la memoria reubicándose a través de la RAM. Mientras lo hace, la CPU imprime la dirección actual del programa en el CRT y luego obtiene la instrucción en esa dirección. Si los IC de RAM están bien en esa dirección, la CPU reubica el programa de prueba en la siguiente ubicación de memoria, imprime la nueva dirección y repite el procedimiento. Pero, si uno de los IC de RAM es lo suficientemente lento como para devolver un patrón de bits incorrecto, la CPU malinterpretará la instrucción y se comportará de forma impredecible. Sin embargo, es probable que la pantalla se bloquee mostrando la dirección del IC defectuoso. Esto reduce el problema a ocho IC, lo que es una mejora con respecto a tener que verificar hasta 32. […] El […] programa realizará una prueba de gusano enviando una instrucción RST 7 (RESTART 7) desde el extremo inferior de la memoria hasta la última dirección de trabajo. El resto del programa permanece estacionario y se encarga de mostrar la ubicación actual del comando RST 7 y su reubicación . Por cierto, el programa se llama prueba de gusano porque, a medida que la instrucción RST 7 avanza por la memoria, deja un rastro viscoso de NOP (NO OPERATION). […]
  19. ^ Steinman, Jan W. (1986-09-01). Escrito en West Linn, Oregon, EE. UU. "La prueba de memoria del gusano". El derecho a ensamblar (TRTA). Revista de herramientas de software del Dr. Dobb para el programador profesional . 11 (9). Redwood City, California, EE. UU.: M&T Publishing, Inc. / The People's Computer Company : 114–115 (662–663). ISSN  1044-789X. #119. ark:/13960/t74v34p9p CODEN  DDJOEB . Consultado el 13 de diciembre de 2021 .[19] (2 páginas)
  20. ^ Steinman, Jan W. (1986). "III. Rutinas y técnicas útiles para el 68000, 16. La prueba de memoria del gusano" (PDF) . Escrito en West Linn, Oregon, EE. UU. Dr. Dobb's Toolbook of 68000 Programming . Nueva York, EE. UU.: Brady Book / Prentice Hall Press / Simon & Schuster, Inc. pp. 341–350. ISBN 0-13-216649-6LCCN  86-25308. Archivado (PDF) del original el 13 de diciembre de 2021. Consultado el 13 de diciembre de 2021 .(1+5+10+1 páginas)
  21. ^ Dewdney, Alexander Keewatin (marzo de 1985). «Computer Recreations - A Core War bestiary of viruses, worms and other threats to computer memorys» (Recreaciones informáticas: un bestiario de virus, gusanos y otras amenazas a las memorias informáticas de la Guerra del Núcleo). Scientific American . 285 : 38–39. Archivado desde el original el 4 de julio de 2017. Consultado el 4 de julio de 2017 .

Lectura adicional