Bibliotecas de ligação dinâmica (DLLs)

Bibliotecas de ligação dinâmica (DLLs) As shared libraries existentes no mundo Unix e utilizadas na UC de PSC têm como equivalente no Windows as chamadas DLLs (Dynamic Link Libraries). O termo no mundo Linux remete para a ideia de partilha (do código) da shared library entre as aplicações cliente. Já no Windows dá-se ênfase à ideia ao tipo de ligação (dinâmica) do código da biblioteca com os seus clientes. Na verdade os dois aspectos são duas faces da mesma moeda: a partilha da biblioteca entre aplicações apenas é possível pelo facto da ligação ser dinâmica. Tal como nas shared libraries, nas DLLs a ligação com os clientes pode ocorrer em dois tempos: em tempo de carregamento com a aplicação cliente (ligação implícita) e a pedido explícito (de forma programática) das aplicações (ligação explícita). 04/04/2016 Sistemas Operativos 1

Referência a variáveis globais em código PIC em IA32 Na imagem em memória de uma biblioteca/programa, a região de dados está sempre a seguir à respetiva região de código. A distância entre uma instrução e uma variável global pertencentes ao mesmo programa/biblioteca é constante. Os factos anteriores permitem o acesso PIC a variáveis globais através de uma tabela de indirecção (a Global Offset Table - GOT) com as seguintes características: Posicionada no inicio do segmento de dados. Preenchida durante a ligação dinâmica. Cada entrada tem o endereço de uma variável global. /* global liba var */ int x; /* liba x access */ x=0; acesso PIC a x call.l1 no código de liba.l1: pop ebx add ebx,.gotliba-.l1 mov eax, [ebx+idx_x] mov [eax], 0x0 Process Address Space Stack Other Libs LibA,.bss GOT of LibA LibA Heap App,.bss App 04/04/2016 Sistemas Operativos 2

Bibliotecas de ligação dinâmica (DLLs) - vantagens e desvantagens Relativamente à construção de executáveis auto-suficientes a ligação dinâmica tem as seguintes vantagens: Minimização de espaço em disco ocupado pelas aplicações Minimização de memória por via da partilha de regiões da DLL entre aplicações cliente (regiões de código, regiões de dados read/only e mesmo de dados read/write através do mecanismo de copy-on-write) Facilita a manutenção evolutiva ( é possível modificar a implementação ou corrigir bugs nas DLL s) sem necessidade de reconstrução dos executáveis cliente. Possibilidade de criar aplicações extensíveis por via do carregamento explícito de DLL s. Também tem algumas desvantagens: Distribuição de aplicações mais complicada como consequência da árvore de dependências associada (notem que as DLL s podem ser elas próprias clientes de outras DLL s...) Maior tempo de carregamento das aplicações no caso do carregamento implícito de potencialmente muitas dezenas ou mesmo centenas de DLL s. Contudo, as vantagens sobrepôem-se em muito às vantagens... 04/04/2016 Sistemas Operativos 3

DLL s ligação estática na construção e dinâmica no carregamento x.dll.reloc app.exe process virtual address space import stubs x.lib.reloc.idata (Import Tables) app.obj.reloc A secção apenas existe no caso do build especificar DYNAMICBASE:YES StaticLinker (Link.exe) Construção do Executável (Ligação estática) app.exe.reloc.idata (Lookup and address Import Tables).edata Dynamic Linker (ntdll.dll) x.dll app.exe Ligação dinâmica no carregamento do executável.idata (Import address Table) 04/04/2016 Sistemas Operativos 4

DLL s Detalhe da ligação dinâmica app.exe PE header app base address.reloc (RVA table).idata Import Name Table Import Address Table x.dll Dynamic Linker (ntdll.dll) app.exe process virtual address space.idata (Import Tables) x.dll PE header dll base address.reloc (RVA table).edata Export Name Table Export Address Table (RVAs) app.exe 04/04/2016 Sistemas Operativos 5

dll necessidade de relocalização Por omissão o código e os dados da DLL são localizados na ligação estática a partir de 0x10000000. O código de acesso a variáveis globais (e às tabelas de import de outras dll s de que esta dependa) foi gerado tendo em conta essa base. O que fazer se a dll não puder ser carregada nesse endereço? Dump of file dllmath.dll OPTIONAL HEADER VALUES 10B magic # (PE32) 10.00 linker version 3600 size of code 3600 size of initialized data 0 size of uninitialized data 110C8 entry point (100110C8) @ILT+195( DllMainCRTStartup@12) 1000 base of code 1000 base of data 10000000 image base (10000000 to 1001AFFF) 1000 section alignment função para guardar em variável global (estática) a dimensão da página obtida via GetSystemInfo static int savedpagesize; int GetPageSize() { SYSTEM_INFO si; if (savedpagesize == 0) { GetSystemInfo(&si); savedpagesize=si.dwpagesize; } return savedpagesize; } Excerto do código gerado para a função, localizado de acordo com o link base address por omissão 100113A4 call 100113B1 mov 100113B4 mov dword ptr [ imp GetSystemInfo@4 (10018168h)] eax,dword ptr [ebp-24h] savedpagesize (10017130h),eax 04/04/2016 Sistemas Operativos 6

Mecanismo de relocalização Os ficheiros imagem (dlls e executáveis) contém uma secção (.reloc) que é essencialmente uma tabela de RVAs que indica referência a endereços que necessitam de relocalização (se mudar o endereço base de carregamento). Em tempo de carregamento essas posições de memória são modificadas de acordo com o novo endereço base. Mas o que acontece se houver necessidade de relocalização da DLL no caso desta ser partilhada (como é usual paras DLL s third party )? Porque razão os executáveis também contêm uma secção.reloc se são sempre carregados no endereço especificado em tempo de ligação? Excerto da tabela de relocações referente ao código do slide anterior e obtida através da opção relocations do comando dumpbin. As colunas representam, respectivamente, o RVA, o tipos da relocação, o valor actual e o símbolo referido AE6 HIGHLOW 10018168 imp GetSystemInfo@4 AF5 HIGHLOW 10017130 _savedpagesize 04/04/2016 Sistemas Operativos 7

Optimizações DLL rebase e DLL bind O utilitário rebase permite efectuar a relocalização antecipada de uma dll para o endereço especificado de modo a evitar a recolocação em tempo de carregamento. Deste modo consegue-se maior eficiência em tempo de carregamento e utilização da memória. As dll s do windows estão todas rebased para endereços que evitam colisões. Vantagens de um sistema operativo proprietário REBASE b newbase image-name O comando bind permite efectuar a ligação dinâmica de forma antecipada, isto é, iniciar as import address tables de acordo com os endereços base especificados nas dll s de que depende a imagem sobre a qual é efectuada o bind. Evita a ligação dinâmica se as dll s não forem alteradas e forem carregadas no endereço pré-definido. Caso contrário a ligação dinâmica é efectuada. BIND u image-name 04/04/2016 Sistemas Operativos 8

Produção e consumo de bibliotecas de ligação dinâmica(dll s) definir DLLMATH_EXPORTS apenas no build da DLL #include "stdafx.h" #include "dllmath.h" int add(int oper1, int oper2) { return oper1 + oper2; } #ifdef DLLMATH_EXPORTS #define MATH_API _declspec(dllexport) #else #define MATH_API _declspec(dllimport) #endif #ifdef cplusplus extern C { #endif MATH_API int add(int op1, int op2); #ifdef cplusplus } #endif dllmath.c #include <stdafx.h> #include dllmath.h int _tmain(int argc, _TCHAR* argv[]) { } dllmath.h _tprintf(_t("%d\n"), add(3,5)); ficheiro de include, partilhado entre DLL e clientes que inclui as funções exportadas e tipos usados nos respectivos parâmetros. mathclient.c other libs & objs build (compile and link) build (compile and link) other libs & obs dllmath.dll dllmath.lib mathclient.exe depends on 04/04/2016 Sistemas Operativos 9

Produção e consumo de Bibliotecas de Ligação Dinâmica(DLL s) all: dllmath.dll mathclient.exe Exemplo de utilização do compilador e do linker em comandos de linha para a produção e consumo de dll s. O makefile exemplifica os comandos necessários, admitindo que as fontes estão na mesma directoria. dllmath.dll: dllmath.obj dllmain.obj link /DLL dllmath.obj dllmain.obj dllmath.obj: dllmath.c cl /c /D dllmath_exports dllmath.c mathclient.exe: mathclient.obj link mathclient.obj dllmath.lib mathclient.obj: mathclient.c cl /c /MD mathclient.c Utilizar a import library (msvcrtd.lib) associada à versão dll do runtime do C (msvcr100.dll). Na sua omissão é usada a biblioteca estática com o runtime (libcmtd.lib). Notem a diferença de tamanho do executável entre os dois casos. 04/04/2016 Sistemas Operativos 10

dumpbin (exports & imports) Dump of file dllmath.dll File Type: DLL Section contains the following exports for DLLMATH.dll 00000000 characteristics 4D9835A0 time date stamp Sun Apr 03 09:53:52 2011 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00001000 add Summary dumpbin /exports dllmath.dll 2000 2000.rdata 1000.reloc 5000 Inicialmente os linkers colocavam a tabela de exports na secção.edata. Actualmente também podem ser encontradas na secção de dados constantes (.rdata). dumpbin /imports mathclient.exe Dump of file mathclient.exe File Type: EXECUTABLE IMAGE Section contains the following imports: dll2.dll 4020B4 Import Address Table 4022A8 Import Name Table 0 add MSVCR100.dll 402050 Import Address Table 402244 Import Name Table 5D7 printf 573 exit 3C9 _onexit KERNEL32.dll 402000 Import Address Table 4021F4 Import Name Table 1C0 GetCurrentProcess 4C0 TerminateProcess Summary 1000 1000.rdata 1000.reloc 1000 Neste caso as tabelas de import também ficaram na secção.rdata 04/04/2016 Sistemas Operativos 11

Convenções de chamada Por omissão, na chamada de funções, na convenção usada por omissão pelo compilador de C/C++, o chamador desempilha os argumentos (add esp, n). No Windows é usada, por razões históricas, outra convenção de chamada. A função invocada é que desempilha os argumentos (ret n). Usa-se o atributo do compilador stdcall (ou a macro equivalente WINAPI) a prefixar o nome da função, para especificar este comportamento. Tal opção permite poupar algum código pois o ajuste do stack fica centralizado. Usando a assinatura DLLMATH_API int WINAPI add(int op1, int op2) para a função exportada, as tabelas de export da dll e import do executável sofrem as seguintes modificações: Dump of file dllmath.dll File Type: DLL Section contains the following exports for DLLMATH.dll ordinal hint RVA name 1 0 00001000 _add@8 Dump of file mathclient.exe File Type: EXECUTABLE IMAGE Section contains the following imports: dll2.dll 4020B4 Import Address Table 4022A8 Import Name Table 0 _add@8 O nome passa a estar decorado com a inclusão da dimensão em bytes dos argumentos a passar à função 04/04/2016 Sistemas Operativos 12

Ligação implícita e explícita A ligação com uma DLL pode ser feita em dois tempos: Em tempo de carregamento do executável quando o executável depende da DLL através de uma import table produzida pela ligação estática com a import library associada à DLL. Neste caso, a ligação dizse automática ou implícita. Em tempo de execução a pedido explícito do programa. Neste caso a ligação diz-se manual ou explícita. Desta forma é possível, por exemplo, escolher a dll a usar em tempo de execução ou estender as funcionalidades da aplicação. 04/04/2016 Sistemas Operativos 13

Ligação explícita modelo computacional O Windows expõe as seguintes funções para tirar partido da ligação explícita: O mesmo que TCHAR * HMODULE WINAPI LoadLibrary( LPCTSTR lpfilename ); FARPROC WINAPI GetProcAddress( HMODULE hmodule, LPCSTR lpprocname ); BOOL WINAPI FreeLibrary(HMODULE hmodule ); typedef int (WINAPI * AddFuncPtr)(int i1, int i2); O mesmo que char *. É um dos raros casos em que na Windows API se utilizam forçosamente caracteres a 8 bits. Notem a boa prática de especificar através de um typedef a assinatura da função a invocar. Na versão da dll que expõe a função usando a convenção de chamada stdcall (WINAPI) teremos de ter o cuidado de incluír a convenção ou naturalmente o stack é incorrectamente ajustado. Notem também a utilização do nome decorado na função GetProcAddress. int _tmain(int argc, _TCHAR* argv[]) { HMODULE hlib; AddFuncPtr addfunc; } hlib = LoadLibrary(_T("DLL2.DLL")); addfunc = (AddFuncPtr) GetProcAddress(hLib, "_add@8" ); if (addfunc==null) { _tprintf(_t("gelasterror=%d\n"), GetLastError()); return 1; } _tprintf(_t("%d\n"), addfunc(3,5)); FreeLibrary(hLib); return 0; 04/04/2016 Sistemas Operativos 14

dll entry point: DllMain As dll s podem ter um entry point (DllMain). O entry point é invocado nas seguintes situações, entre outras que veremos adiante: Da primeira vez que a dll é carregada no espaço de endereçamento de um processo (DLL_PROCESS_ATTACH), quer na ligação implícita quer na ligação explícita. Quando a dll for retirada do espaço de endereçamento (DLL_PROCESS_DETACH). Isto ocorre no último FreeLibrary ou em fase de terminação do processo. O código seguinte exemplifica a utilização: #include "stdafx.h" sinónimo de WINAPI BOOL APIENTRY DllMain( HMODULE hmodule, DWORD reason_for_call, LPVOID reserved){ switch (reason_for_call) { case DLL_PROCESS_ATTACH: _tprintf(_t("starting Math DLL\n")); break; //. Outros casos case DLL_PROCESS_DETACH: _tprintf(_t("ending DLLW2\n")); break; } return TRUE; } 04/04/2016 Sistemas Operativos 15

Algoritmo de LoadLibrary Thread calls LoadLibrary bib: Windows via C/C++, Richter, fig. 20-2 Is DLL already mapped in process address space? NO Can the system find the specified DLL file? NO YES Increment DLL s usage count Map DLL into process address space YES NO Is the usage count equal to 1? YES Call the library s DllMain function with a value of DLL_PROCESS_ATTACH Did DllMain return TRUE? YES Return hinstdll (load address) of the library NO Decrement DLL s usage count and unmap DLL from process address space Return NULL 04/04/2016 Sistemas Operativos 16

Objectivos de aprendizagem Identificar as vantagens/desvantagens da utilização de bibliotecas de ligação dinâmica versus bibliotecas de ligação estática. Entender os passos envolvidos na construção e consumo de DLL s, nomeadamente a construção de ficheiros de include partilhados e o papel das bibliotecas de ligação estática (libs) associadas às DLLs. Explicar a existência de várias convenções de chamada ( cdecl, stdcall, fastcall) e a necessidade de garantir o match entre clientes (aplicações) e fornecedores (DLLs). Compreender o mecanismo de ligação dinâmica, explicando o papel das tabelas de importação e exportação. Explicar a potencial necessidade de relocalização do código das DLLs, o processo de relocalização propriamente dito e os seus inconvenientes. Compreender o interesse de utilitários como o rebase e o bind no que concerne, respectivamente, à necessidade de evitar relocalizações e a optimizar o processo de ligação dinâmica implícita. 04/04/2016 Sistemas Operativos 17

Bibliografia Windows via C/C++, Fifth Edition, Jeffrey Richter e Christophe Nasarre Cap.19 DLL basics Cap.20 DLL advanced techniques 04/04/2016 Sistemas Operativos 18