abicompat - Online na nuvem

PROGRAMA:

NOME

abicompat - verificar compatibilidade ABI

O abicompat verifica se um aplicativo vinculado a uma determinada biblioteca compartilhada ainda está
ABI compatível com uma versão subsequente dessa biblioteca. Se a nova versão do
biblioteca apresenta uma incompatibilidade ABI, então abicompat sugere ao usuário o que exatamente
essa incompatibilidade é.

INVOCAÇÃO

abicompat [opções] [ ]

OPÇÕES

· --Socorro

Exibe uma breve ajuda sobre o comando e sai.

· --versão | -v

Exiba a versão do programa e saia.

· --list-indefinidos-símbolos | -u

Exiba a lista de símbolos indefinidos do aplicativo e saia.

· --show-base-nomes | -b

No relatório resultante emitido pela ferramenta, esta opção torna a aplicação e
as bibliotecas devem ser referenciadas apenas por seus nomes de base; não por um nome absoluto completo. Esse
pode ser útil para uso em scripts que desejam comparar nomes do aplicativo e
bibliotecas independentemente de quais são seus nomes de diretório.

· --app-debug-info-dir

Defina o caminho para o diretório no qual as informações de depuração do aplicativo estão
deveria ser colocado para fora. Isso é útil para binários de aplicativos para os quais a depuração
as informações estão em um conjunto separado de arquivos.

· --lib-debug-info-dir1

Defina o caminho para o diretório sob o qual as informações de depuração da primeira versão
da biblioteca compartilhada deve ser definida. Isso é útil para a biblioteca compartilhada
binários para os quais as informações de depuração estão em um conjunto separado de arquivos.

· --lib-debug-info-dir2

Defina o caminho para o diretório em que as informações de depuração da segunda versão
da biblioteca compartilhada deve ser definida. Isso é útil para a biblioteca compartilhada
binários para os quais as informações de depuração estão em um conjunto separado de arquivos.

· --no-show-locs
Não mostre informações sobre onde no segundo compartilhado biblioteca o respectivo
tipo foi alterado.

· - modo fraco

Isso aciona o modo fraco de abicompat. Neste modo, apenas uma versão do
biblioteca é necessária. Ou seja, abicompat é invocado assim:

abicompat --weak-mode

Observe que o - modo fraco opção pode até ser omitida se apenas uma versão do
a biblioteca é fornecida, junto com o aplicativo; nesse caso, abicompat automaticamente
muda para operar em modo fraco:

abicompat

Neste modo fraco, os tipos de funções e variáveis ​​exportadas pela biblioteca e
consumido pelo aplicativo (como nos símbolos dessas funções e variáveis
são indefinidos no aplicativo e são definidos e exportados pela biblioteca) são
em comparação com a versão desses tipos conforme esperado pelo aplicativo. E se estes
duas versões de tipos são diferentes, abicompat diz ao usuário quais são as diferenças
são.

Em outras palavras, neste modo, abicompat verifica se os tipos de funções e
variáveis ​​exportadas pela biblioteca significam a mesma coisa que o que o aplicativo
espera, no que diz respeito à ABI.

Observe que, neste modo, abicompat não detecta funções ou variáveis ​​exportadas
(símbolos) que são esperados pelo aplicativo, mas que são removidos da biblioteca.
É por isso que é chamado fraco modo.

RETORNO VALORES

O código de saída do abicompat comando é 0 se a ABI dos binários sendo
comparados são iguais ou diferentes de zero se forem diferentes ou se a ferramenta tiver encontrado um erro.

No último caso, o código de saída é um campo de bits de 8 bits em que cada bit tem um
significado específico.

O primeiro bit, de valor 1, denominado ABIDIFF_ERROR significa que houve um erro.

O segundo bit, de valor 2, denominado ABIDIFF_USAGE_ERROR significa que houve um erro no caminho
o usuário invocou a ferramenta. Pode ser definido, por exemplo, se o usuário invocou a ferramenta
com uma chave de linha de comando desconhecida, com um número ou argumento errado, etc. Se este bit for
definido, então o ABIDIFF_ERROR bit deve ser definido também.

O terceiro bit, de valor 4, denominado ABIDIFF_ABI_CHANGE significa que a ABI dos binários sendo
comparados são diferentes.

O quarto bit, de valor 8, denominado ABIDIFF_ABI_INCOMPATIBLE_CHANGE significa o ABI do
binários comparados são diferentes de maneira incompatível. Se este bit estiver definido, então o
ABIDIFF_ABI_CHANGE bit deve ser definido também. Se o ABIDIFF_ABI_CHANGE está definido e o
ABIDIFF_INCOMPATIBLE_CHANGE is NÃO definido, então isso significa que os ABIs que estão sendo comparados podem
ou pode não ser compatível. Nesse caso, um ser humano precisa revisar as mudanças de ABI
para decidir se eles são compatíveis ou não.

Os bits restantes não são usados ​​no momento.

USO EXEMPLOS

· Detectar uma possível incompatibilidade ABI em uma nova versão da biblioteca compartilhada:

$ cat -n teste0.h
1 estrutura foo
2 {
3int m0;
4
5 foo ()
6: m0 ()
7{}
8};
9
10 foo *
11 first_func ();
12
13 vazio
14 second_func (foo &);
15
16 vazio
17 third_func ();
$

$ gato -n teste-app.cc
1 // Compilar com:
2 // g ++ -g -Wall -o test-app -L. -ltest-0 test-app.cc
3
4 #include "test0.h"
5
6 int
7 principais ()
8 {
9 foo * f = first_func ();
10 second_func (* f);
11 retorna 0;
12}
$

$ cat -n teste0.cc
1 // Compile isso com:
2 // g ++ -g -Wall -shared -o libtest-0.so test0.cc
3
4 #include "test0.h"
5
6 foo *
7 first_func ()
8 {
9 foo * f = novo foo ();
10 retorno f;
11}
12
13 vazio
14 second_func (foo &)
15 {
16}
17
18 vazio
19 third_func ()
20 {
21}
$

$ cat -n teste1.h
1 estrutura foo
2 {
3int m0;
4 char m1; / * <- um novo membro foi adicionado aqui! * /
5
6 foo ()
7: m0 (),
8 m1 ()
9{}
10};
11
12 foo *
13 first_func ();
14
15 vazio
16 second_func (foo &);
17
18 vazio
19 third_func ();
$

$ cat -n teste1.cc
1 // Compile isso com:
2 // g ++ -g -Wall -shared -o libtest-1.so test1.cc
3
4 #include "test1.h"
5
6 foo *
7 first_func ()
8 {
9 foo * f = novo foo ();
10 retorno f;
11}
12
13 vazio
14 second_func (foo &)
15 {
16}
17
18 / * Vamos comentar a definição de third_func ()
19 vazio
20 third_func ()
21 {
22}
23 * /
$

· Compilar a primeira e a segunda versões das bibliotecas: libtest-0.so e
libtest-1.so:

$ g ++ -g -Wall -shared -o libtest-0.so test0.cc
$ g ++ -g -Wall -shared -o libtest-1.so test1.cc

· Compilar o aplicativo e vinculá-lo à primeira versão da biblioteca,
criando o aplicativo de teste binário:

$ g ++ -g -Wall -o test-app -L. -ltest-0.so test-app.cc

· Agora usa abicompat para ver se libtest-1.so é compatível com ABI com o app, com respeito
para a ABI de libtest-0.so:

$ abicompat test-app libtest-0.so libtest-1.so
O arquivo ELF 'test-app' pode não ser compatível com ABI 'libtest-1.so' devido a diferenças com 'libtest-0.so' abaixo:
Resumo das alterações de funções: 0 removidas, 2 alteradas, 0 funções adicionadas
Resumo das alterações das variáveis: 0 removida, 0 alterada, 0 variável adicionada

2 funções com alguma mudança indireta de subtipo:

[C] 'function foo * first_func ()' tem algumas mudanças indiretas de subtipo:
tipo de retorno alterado:
em apontado para o tipo 'struct foo':
tamanho alterado de 32 para 64 bits
1 inserção de membro de dados:
'char foo :: m1', no deslocamento 32 (em bits)
[C] 'function void second_func (foo &)' tem algumas alterações indiretas de subtipo:
o parâmetro 0 do tipo 'foo &' tem alterações de subtipo:
tipo referenciado 'struct foo' alterado, conforme relatado anteriormente

$

· Agora utilize o modo fraco da abicompat, ou seja, disponibilizando apenas o aplicativo e o
nova versão da biblioteca:

$ abicompat --modo fraco test-app libtest-1.so
funções definidas na biblioteca
'libtest-1.so'
têm subtipos que são diferentes de quais aplicativos
'test-app'
espera:

função foo * first_func ():
tipo de retorno alterado:
em apontado para o tipo 'struct foo':
tamanho alterado de 32 para 64 bits
1 inserção de membro de dados:
'char foo :: m1', no deslocamento 32 (em bits)

$

Use abicompat online usando serviços onworks.net