Question

I’ve got a small static library (.a). In the static library is a pointer that points to a large, statically allocated, 1D array.

When I link my code to this library, the pointer’s address is hardcoded in various locations, easily found through the disassembly. The issue is, I’d like my code to be able to have access to this array (the library is faulting, and I want to know why).

Naturally, it would be trivial to get that pointer by disassembling, hardcoding that address into my code, and then recompiling. That wouldn’t be a problem except the library can be configured in different ways with other modules, and the array’s pointer changes depending on what modules are linked in.

What are my options for getting that pointer? Because the starting state of the array is predictable, I could walk through memory, catching segfaults with a signal handler, until I found something that looks reasonable. Is there a better way?

Answer 1

Since your library is a .a archive, I’ll assume you are on some kind of UNIX.

The global array should have a symbolic name associated with it. Your job would be easier or harder depending on what kind of symbol describes it.

If there is a global symbol describing this array, then you can just reference it directly, e.g.

extern char some_array[];
for (int i = 0; i < 100; i++) printf("%2d: 0x%2x\n", i, some_array[i]);

If the symbol is local, then you can first globalize it with objcopy --globalize-symbol=some_array, then proceed as above.

So how can you determine what is the symbol describing that array? Run objdump -dr foo.o, where foo.o contains instructions which you know reference that array. The relocation that will appear next to the referring instruction will tell you the name.

Finally, run nm foo.o | grep some_array. If you see 00000XX D some_array, you are done — the array is globally visible (same for B). If you see 000XX d some_array, you need to globalize it first (likewise for b).

Update:

The -dr to objectdump didn’t work

Right, because the symbol turned out to be local, the relocation probably referred to .bss + 0xNNN.

00000000006b5ec0 b grid
00000000006c8620 b grid
00000000006da4a0 b grid
00000000006ec320 b grid
00000000006fe1a0 b grid

You must have run nm on the final linked executable, not on individual foo.o objects inside your archive. There are five separate static arrays called grid in your binary, only the first one is the one you apparently care about.

declaring “extern int grid[];” and using it gives an undefined reference

That’s expected for local symbols: the code in the library was something like:

// foo.c
static char grid[1000];

and you can’t reference this grid from outside foo.o without globalizing the symbol first.

I’m not allowed to run a changed binary of the library on our server for security reasons

I hope you understand that that argument is total BS: if you can link your own code into that binary, then you can do anything on the server (subject to user-id restrictions); you are already trusted. Modifying third-party library should be the least worry of the server’s admin if he doesn’t trust you.