Estoy luchando por convertir un C-programa vinculado con ld, de la cadena de herramientas gnu para que se compile como un proyecto visual-studio (2005). El programa pone .data-symbols en diferentes segmentos y durante una fase de inicialización copia datos entre segmentos. Los punteros al inicio y al final de los segmentos se definen en la secuencia de comandos ld linker.¿Cómo hacer referencia al inicio de un segmento definido por el usuario en un proyecto de Visual Studio?
entiendo cómo localizar las variables en los diferentes, definidos por el usuario segmentos, pero que no he sido capaz de encontrar la manera de definir las constantes de engarce como _start_of_my_segment o si hay algo similar a un guión enlazador en Visual Estudio.
Mi objetivo es ser capaz de compilar el programa con, prefferably no hay modificaciones en el código fuente que se refiere a los símbolos enlazador definidos, pero con mi propio diseño personalizado de los datos en el proyecto de Visual Studio .
A continuación se muestra algunos ejemplos de código C que ilustra lo que me gustaría hacer y una (reducidos al mínimo, posiblemente sintaxis incorrecta) versión del script maquillaje utilizado cuando se enlaza con gcc/ld.
¡Cualquier sugerencia sería muy apreciada!
#pragma data_seg("MY_DATA_FOO")
#pragma data_seg("MY_DATA_BAR")
#pragma comment(linker, "/section:MY_DATA_BAR,R")
__declspec(allocate("MY_DATA_FOO")) int foo1;
__declspec(allocate("MY_DATA_FOO")) int foo2;
__declspec(allocate("MY_DATA_BAR")) int bar1 = 1;
__declspec(allocate("MY_DATA_BAR")) int bar2 = 2;
#pragma data_seg()
void test() {
foo1 = bar1;
foo2 = bar2;
// i would rather do this as
//extern unsigned int __start_of_MY_DATA_FOO;
//extern unsigned int __start_of_MY_DATA_BAR;
//extern unsigned int __size_of_MY_DATA_BAR;
//memcpy(__start_of_MY_DATA_FOO, _start_of_MY_DATA_BAR, _size_of_MY_DATA_BAR);
}
Pseudo enlace-script (lo que sería el equivalente para Visual Studio
MEMORY
{
foo: org=0x1000, len=0x100
bar: org=0x2000, len=0x100
}
SECTIONS
{
GROUP:
{
MY_DATA_FOO : {}
__start_of_MY_DATA_FOO = ADDR(MY_DATA_FOO);
__end_of_MY_DATA_FOO = .;
__size_of_MY_DATA_FOO = SIZEOF(MY_DATA_FOO);
} > foo
GROUP:
{
MY_DATA_BAR : {}
__start_of_MY_DATA_BAR = ADDR(MY_DATA_BAR);
__end_of_MY_DATA_BAR = .;
__size_of_MY_DATA_BAR = SIZEOF(MY_DATA_BAR);
} > bar
}
Esto es realmente algo que no se debe hacer. Seguramente hay formas portátiles de escribir el mismo programa. Parece que alguien pensó que era inteligente engañando con componentes internos de cadena de construcción de bajo nivel en lugar de usar C correctamente ... Está un paso por encima de suponer que puede acceder a variables locales desde una función llamada en su llamador después de que regrese ... –
@ R .: Raras pero ocasionalmente decentes razones para usar este patrón. Lo he usado para agregar verificaciones de depuración. En versiones de lanzamiento, mis objetos son independientes y no se conocen entre sí. Pero para la depuración, lo hacen. La forma "legal C/C++" es un registro central para rastrear esto, hecho solo para la depuración, en realidad es mucho más mantenimiento para más de 200 cosas que este enfoque (este enfoque es automático). Por otro lado, la importabilidad es un costo diferente que esto trae. – VoidStar