Why no call fstab64 after read? And can this be a problem?

Question

I want to create a new dynamic library instead of another, the source code of which is lost. I have created a library with exported functions, but the program does not load it. Conclusion Strace is almost the same, the only difference is that in the case of loading my library after the call to read() there is no call to fstat64().

strace original library:

open("/usr/local/lpr/li2/libSA.so", O_RDONLY) = 12
read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3409\0"...,     1024) = 1024
fstat64(12, {st_mode=S_IFREG|0644, st_size=46166, ...}) = 0
old_mmap(NULL, 40256, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0x40150000
mprotect(0x40159000, 3392, PROT_NONE)   = 0
old_mmap(0x40159000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 12, 0x8000) = 0x40159000
close(12)                               = 0

my library:

open("/usr/local/lpr/li2/libSA.so", O_RDONLY) = 12
read(12, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\210\0\0"...,     1024) = 1024
close(12)                               = 0
time(NULL)

Are you linking with your library or loading it with `dlopen`? — Some programmer dude, May 29 '19 at 12:06
Then do `dlopen` fail or succeed? If it fails, with what error? — Some programmer dude, May 29 '19 at 13:05

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

You're trying to load a 64-bit shared object into a 32-bit process.

The ELF header read by these two read() calls:

read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3409\0"...,     1024) = 1024

and

read(12, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\210\0\0"...,     1024) = 1024

differ. Note that the fifth byte in the first read() is 1. That's the successful load of a 32-bit shared object.

That fifth byte is 2 on the unsuccessful attempt - and that 2 means that the shared object is a 64-bit shared object.

You likely need to compile and link with the -m32 option.

Why no call fstab64 after read? And can this be a problem?

1 Answers1