Date 1 - 4 of 4
ww07 - Agenda
Today we'll continue the investigation on the Telltale Safety App address space as per KSR_002 doc
followup wrt identification of symbols used by an empty program, since it was pulling in libc.
The program "test.c":
while (1); /* Infinite loop */
gcc test.c -o test
My initial thought of using prelink did not work, because apparently prelink has been bitrotting at least since 2017.
Admittedly, also yours truly had not used it since 2010. For some reason, it's still around, though.
Anyways, there are various other ways to obtain the desired information.
One of them is to use nm:
nm -D test
From man nm:
"U" The symbol is undefined.
"w" The symbol is a weak symbol that has not been specifically tagged as a weak object symbol. When a weak defined symbol is linked with a normal defined symbol, the normal
defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the symbol is determined in a system-specific manner
without error. On some systems, uppercase indicates that a default value has been specified.
Those weak housekeeping symbols seem to be the reason why libc is being pulled in.
On Mon, Feb 21, 2022 at 9:00 AM Igor Stoppa via lists.elisa.tech <istoppa=nvidia.com@...> wrote:
Thanks a lot for your analysis. Interestingly I have now compiled the dummy program using
"gcc -nostdlib test1.c"
The compilation succeeded and I ran the program; the resulting maps is:
[gpaoloni@fedora test]$ cat /proc/17846/maps
00400000-00401000 r--p 00000000 00:21 9889982 /home/gpaoloni/test/a.out
00401000-00402000 r-xp 00001000 00:21 9889982 /home/gpaoloni/test/a.out
00402000-00403000 r--p 00002000 00:21 9889982 /home/gpaoloni/test/a.out
7ffde680e000-7ffde682f000 rw-p 00000000 00:00 0 [stack]
7ffde68da000-7ffde68de000 r--p 00000000 00:00 0 [vvar]
7ffde68de000-7ffde68e0000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Now the mappings, as expected, do not show any glibc one.
We can see a read only area where we have the code and the exception handling frame. As next steps I will try to understand
where and how these mappings are maintained within the Kernel.
> As next steps I will try to understand where and how these mappings are maintained within the Kernel.
struct task_struct contains
struct mm_struct *mm
struct mm_struct *active_mm
which are the memory maps used by a process (and its threads)
|1 - 4 of 4|