Partilhar via


Escolhendo quais símbolos públicos remover

O PDBCopy fornece as opções -f e -F para que você possa remover um conjunto arbitrário de símbolos públicos de um arquivo de símbolo despojado, deixando apenas os símbolos que seu público precisa acessar para executar a depuração.

Um uso comum do PDBCopy é criar uma versão especial do arquivo de símbolo para uso pela Microsoft em seu programa OCA (Análise de Falhas Online). O OCA pode designar determinadas funções como inertes, o que significa que, se a função for encontrada no rastreamento de pilha, ela será ignorada. Uma função normalmente seria declarada inerte se fosse simplesmente uma função wrapper ou "passagem" que não executa cálculos significativos. Se essa função for encontrada na pilha em uma análise de falha, pode-se supor que essa função em si não foi uma falha e, no máximo, ela passou dados inválidos ou corrompidos que recebeu de rotinas anteriormente na pilha. Ignorando essas funções, o OCA pode determinar melhor a causa real do erro ou corrupção.

Naturalmente, qualquer função que você deseja declarar "inerte" precisa ser incluída na tabela de símbolos públicos do arquivo de símbolo usado pelo OCA. No entanto, essas não são as únicas funções que precisam ser incluídas, como mostra o exemplo a seguir.

Suponha que você escreva um driver do Windows e use PDBCopy para remover todos os símbolos públicos de seu arquivo de símbolo, exceto FunctionOne e FunctionSix, duas funções inertes. Sua expectativa é que, se FunctionOne ou FunctionSix forem encontrados na pilha após uma falha, eles serão ignorados pelo OCA. Se qualquer outra parte do driver estiver na pilha, a Microsoft fornecerá o endereço de memória correspondente e você poderá usar o endereço para depurar o driver.

No entanto, vamos supor que o driver ocupe a memória no seguinte layout:

Endereço Conteúdo da memória

0x1000

Endereço base do módulo

0x2000

Início do FunctionOne

0x203F

Fim do FunctionOne

0x3000

Início do FunctionSix

0x305F

Fim do FunctionSix

0x7fff

Fim do módulo na memória

Se o depurador encontrar um endereço na pilha, ele selecionará o símbolo com o próximo endereço inferior. Como a tabela de símbolos públicos contém o endereço de cada símbolo, mas nenhuma informação de tamanho, não há como o depurador saber se um endereço realmente está dentro dos limites de qualquer símbolo específico.

Portanto, se ocorrer uma falha no endereço 0x2031, o depurador executado pelo Microsoft OCA identificará corretamente a falha como em FunctionOne. Como essa é uma função inerte, o depurador continua percorrendo a pilha para encontrar a causa da falha.

No entanto, se ocorrer uma falha em 0x2052, o depurador ainda corresponderá esse endereço a FunctionOne, mesmo que ele esteja além do final real dessa função (0x203F).

Consequentemente, você deve incluir no arquivo de símbolo removido não apenas as funções que deseja expor, mas também os símbolos imediatamente após essas funções. Neste exemplo, você gostaria de expor FunctionOne, FunctionTwo, FunctionSix e FunctionSeven:

Endereço Conteúdo da memória

0x1000

Endereço base do módulo

0x2000

Início do FunctionOne

0x203F

Fim do FunctionOne

0x2040

Início de FunctionTwo

0x3000

Início do FunctionSix

0x305F

Fim do FunctionSix

0x3060

Início do FunctionSeven

0x7fff

Fim do módulo na memória

Se você incluir todas essas quatro funções no arquivo de símbolo removido, a análise do Microsoft OCA não tratará erroneamente o endereço 0x2052 como parte do FunctionOne. Neste exemplo, ele assumirá que esse endereço faz parte de FunctionTwo, mas isso não é importante porque você não registrou FunctionTwo com OCA como uma função inerte. O importante é que o endereço 0x2052 é reconhecido como não se enquadrando em uma função inerte e, portanto, o OCA reconhecerá isso como uma falha significativa no driver e poderá informá-lo sobre a falha.

Se você não quiser divulgar os nomes das funções após cada função inerte, poderá inserir funções não importantes em seu código seguindo cada função inerte para que os nomes dessas funções possam ser incluídos no arquivo de símbolo público. Certifique-se de verificar se essas funções adicionadas realmente seguem suas funções inerte no espaço de endereço do binário, pois algumas rotinas de otimização podem alterar isso ou até mesmo remover algumas funções inteiramente.