Date
1 - 4 of 4
ww07 - Agenda
Hi All Today we'll continue the investigation on the Telltale Safety App address space as per KSR_002 doc Thanks Gab |
|
Igor Stoppa
Hello,
followup wrt identification of symbols used by an empty program, since it was pulling in libc. The program "test.c": int main() { while (1); /* Infinite loop */ return 0; } 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 w __cxa_finalize@....5
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U __libc_start_main@...
From man nm: [...] "U" The symbol is undefined. [...] "W"
"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. -- igor |
|
Hi Igor On Mon, Feb 21, 2022 at 9:00 AM Igor Stoppa via lists.elisa.tech <istoppa=nvidia.com@...> wrote: Hello, 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. Thanks Gab
|
|
Igor Stoppa
Hi,
> 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 and struct mm_struct *active_mm which are the memory maps used by a process (and its threads) -- igor |
|