Pergunta

Atualmente, estou portar um projeto com algumas centenas de arquivos de código e dependências em várias bibliotecas de terceiros para o Mac OS. Eu finalmente chegado ao ponto onde o programa é compilado sem avisos ou erros, mas não parece para executar minha própria função principal.

Em vez disso, parece executar alguma outra função principal, que parece pertencer a um terceiro. Esta função escreve alguns dados de diagnóstico para o futuro para o console e saídas depois:

(gdb) continue
Current language:  auto; currently c++
//
// This is an automatically generated file.
// Do not edit.
//

const unsigned short expTable[] =
{
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
...
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
};

Debugger stopped.
Program exited with status value:0.

Eu não posso usar o depurador para descobrir onde este reside principais funções, porque, enquanto o rastreamento de pilha parece válido, gdb não me mostrar o número de arquivos e linha correta nome para cada entrada de pilha (Veja this questão sem solução para detalhes).

A pesquisa levou vários minutos para ser concluído, mas não encontrou nenhum resultado.

Meu projeto está usando SDL entre outras bibliotecas, mas estou atribuição de SDL_Main () e os problemas subjacentes e ter construído o meu projeto em cima de um modelo de projeto SDL perfeitamente bem trabalhar. Por isso, estou certo de que minha própria função principal é válido.

Você tem alguma idéia do que pode estar acontecendo de errado? Estou atualmente fora de idéias sobre como encontrar e remover a função principal desonestos.

Obrigado,

Adrian

EDIT: Como eu só descobri, eu cometi um erro durante a busca de arquivos de arquivo com a string "Este é um gerados automaticamente". Eu encontrei vários arquivos dúzia com a mesma seqüência, todos pertencentes à FreeImage, uma das bibliotecas de terceiros que estou usando. Então, o problema parece estar relacionado com FreeImage, mas eu não sou ainda não tem certeza de como proceder desde que eu compilei FreeImage como uma biblioteca com o MacOs fechados makefile e incluiu apenas a biblioteca. Vou tentar reconstruir uma versão mais recente do FreeImage e vê-lo se que fixa o meu problema.

Foi útil?

Solução

Poderia ser um inicializador para um objeto estático que falha antes de seu main () é chamado?

Outras dicas

Você tem vários principal no binário? Tente usar nm nele. (não deve ser possível, pois ld não vai ligar com duplicatas, mas ir para as libs dinâmicos e olhar para _main lá)

nm a.out | grep -5 _main

Isto deve dar 5 linhas antes e depois de qualquer _main encontrado no binário a.out

Se você tem vários, ver os símbolos que cercam para dicas quais partes eles estão em ...

O próximo passo pode ser a fazer o mesmo em cada lib dinâmica que é usado. Para obter uma lista das bibliotecas dinâmicas utilizadas utilização otool

otool -L a.out

Eu não tenho certeza de como encontrar o outro, mas você pode especificar o seu próprio ponto de entrada explícita e fazer o outro não utilizado. Você pode usar a opção GNU vinculador ld -e para definir a sua entrada ponto.

entrada -e

- entrada = entrada

Use a entrada como o símbolo explícita para a execução início de sua programa, em vez do ponto de entrada padrão. Se não houver sym- bol entrada chamada, o vinculador tentará analisar a entrada como um número, e usar isso como o endereço de entrada (o número será interpretado em 10 de base; você pode usar um 0x líder para a base 16, ou um 0 por base 8).

Para futuros leitores, se você tem esse problema no Windows. A opção vinculador equivalente é / ENTRADA .

Você tentou executar seu executável através nm? Ele pode ser capaz de lhe dar algumas dicas. Eu não acho que seria possível associar um programa com mais de uma função globalmente visível main() chamado, não sei como que gere a acontecer.

olhar através dos arquivos de cabeçalho que você incluir e ver se não há uma definição que remaps main para outra coisa. Este é um velho truque para garantir que a função principal de uma biblioteca é chamado pela primeira vez para fazer alguma configuração. Geralmente, ele acabará por chamar sua função principal, referindo-se ao valor redefinido.

Um corte rápido:

readelf -s -w my_bin_file > temp.txt

Open temp.txt, procurar principal (com FUNC em uma coluna) Suba até encontrar a primeira coluna FILE - este é o arquivo com o ligada principal

.

Editar: Isto só funciona em sabores e amigos GNU Unix. OS X usa o formato de Mach-O, não ELF.

Eu sei que em C, você pode ter um ponto de entrada diferente chamado antes a função principal, que poderia ser uma idéia. O código normalmente se parece com:

void __attribute__ ((constructor)) my_main(void);

Talvez você pode procurar por algo parecido em seu código.

Em C, há também maneiras diferentes para capturar a função principal e chamá-lo após o "real" principal. Alguns biblioteca de threads tem este tipo de hacks, a fim de "preparar" o environnement, scheduler e coisas assim.

Esta não é realmente útil, mas isso pode explicar por que seu principal não é chamado em tudo.

Espero que isso ajude!

Outra nota.

WxWidgets também não definir a sua própria main

A partir aqui

Como em todos os programas, deve haver uma função "main". Sob wxWidgets principal é implementado usando esta macro, o que cria uma instância do aplicativo e inicia o programa.

IMPLEMENT_APP(MyApp)

Parece que você pode ter um arquivo chamado b44ExpLogTable.cpp compilados em seu binário ou algum thirdpart biblioteca. Parece que aquele pequeno programa é gerar uma tabela de exp (), mas, de alguma forma vir a ser importado para o seu projeto (s)

este e isso em fontes FreeImage

Gerar um arquivo de mapa. A maioria dos programas não realmente começar a principal. A mapfile do GCC deve dizer-lhe o endereço de __start ou __executable_start, que você deve ser capaz de quebrar e passo através de ver o que está causando o seu programa para sair.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top