Hi, and thanks for your reply. I totally forgot to take the dynamic loader into consideration, which is my bad.
But another problem is that the peak value cannot align with the max_rss getting from `getrusage` function, which is ~1000KiB. I guess that it has some connection with max_rss inheriting, but I'm not sure about that. Do you have any opinion about it? 杨贺然 <[email protected]> 于2024年6月4日周二 21:37写道： > Hi, and thanks for your reply. I totally forgot to take the dynamic loader > into consideration, which is my bad. > > But another problem is that the peak value cannot align with the max_rss > getting from `getrusage` function, which > is ~1000KiB. I guess that it has some connection with max_rss inheriting, > but I'm not sure about that. Do you have > any opinion about it? > > Valdis Klētnieks <[email protected]> 于2024年6月4日周二 01:44写道： > >> On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said: >> >> > // a.c >> > int main() {} >> > >> > It shows that `memory.peak` of this program is ~500KiB, which does not >> make >> > sense to me. >> >> Makes sense to me... >> >> [~] cat > testnull.c >> int main() {} >> [~] gcc testnull.c >> [~] ldd a.out >> linux-vdso.so.1 (0x00007efc6a650000) >> libc.so.6 => /lib64/libc.so.6 (0x00007efc6a43d000) >> /lib64/ld-linux-x86-64.so.2 (0x00007efc6a652000) >> [~] objdump -d a.out >> >> a.out: file format elf64-x86-64 >> >> >> Disassembly of section .init: >> >> 0000000000401000 <_init>: >> 401000: f3 0f 1e fa endbr64 >> 401004: 48 83 ec 08 sub $0x8,%rsp >> 401008: 48 8b 05 d1 2f 00 00 mov 0x2fd1(%rip),%rax # >> 403fe0 <__gmon_start__@Base> >> 40100f: 48 85 c0 test %rax,%rax >> 401012: 74 02 je 401016 <_init+0x16> >> 401014: ff d0 call *%rax >> 401016: 48 83 c4 08 add $0x8,%rsp >> 40101a: c3 ret >> >> Disassembly of section .text: >> >> 0000000000401020 <_start>: >> 401020: f3 0f 1e fa endbr64 >> 401024: 31 ed xor %ebp,%ebp >> 401026: 49 89 d1 mov %rdx,%r9 >> 401029: 5e pop %rsi >> 40102a: 48 89 e2 mov %rsp,%rdx >> 40102d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp >> 401031: 50 push %rax >> 401032: 54 push %rsp >> 401033: 45 31 c0 xor %r8d,%r8d >> 401036: 31 c9 xor %ecx,%ecx >> 401038: 48 c7 c7 06 11 40 00 mov $0x401106,%rdi >> 40103f: ff 15 93 2f 00 00 call *0x2f93(%rip) # >> 403fd8 <__libc_start_main@GLIBC_2.34> >> 401045: f4 hlt >> 401046: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) >> 40104d: 00 00 00 >> (.....) >> >> Basically, its not *really* a totally null program. You've got the >> dynamic >> loader ld-linux running first, which then *doesn't* run main() directly, >> but >> rather invokes _start, which needs to happen so that __libc_start_main >> can get >> called and initialize stuff lie stdio, malloc, and other such t hings, >> before >> it finally calls main(). >> >> Personally, I'm surprised that ld-linux and glibc initialization can >> finish >> without going over 500k - even more so if shared library text pages are >> included in memory.peak. Somebody else can wade into that mess, I admit >> having been around since kernel 2.5.47 or so, and I never did understand >> the >> memory accounting for shared text pages.... >> >>
_______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
