00:02 <kerneltoast> fche, none of the strings i printed using your stap script there are actually in the -d programs

00:03 <fche> well put more -d's in there :)

00:03 <fche> at this point the unwind data has to be provided to stap ahead of time via -d etc.

00:06 <kerneltoast> got any idea other than using signals?

00:06 <fche> it was just some random glibc function that took function pointers as arguments

00:06 <kerneltoast> oh wait

00:07 <kerneltoast> i see why it works for the programs you listed

00:07 <kerneltoast> because there's no gap between the first section and the second one

00:07 <kerneltoast> 562c5e9fc000-562c5ea05000 r--p 00000000 00:1f 209966 /usr/bin/as

00:07 <kerneltoast> 562c5ea05000-562c5ea53000 r-xp 00009000 00:1f 209966 /usr/bin/as

00:08 <kerneltoast> stap extends the mappings when they're next to each other

00:08 <kerneltoast> php has a gap though

00:09 <kerneltoast> 55e366a00000-55e366ad0000 r--p 00000000 00:1f 298271 /usr/bin/php

00:09 <kerneltoast> 55e366c00000-55e366e65000 r-xp 00200000 00:1f 298271 /usr/bin/php

00:09 <kerneltoast> see the end of the first mapping != the start of the second mapping

00:09 <fche> aha

00:09 <kerneltoast> so the extension fails

00:10 <fche> I couldn't get the analogous test working for /usr/bin/php

00:10 <kerneltoast> i dunno why php is wacky like this

00:10 <kerneltoast> it's only like this in fedora 32+

00:10 <kerneltoast> there might be other binaries with the same deal

00:14 <kerneltoast> so how d'ya feel about it now

00:20 <fche> would like to find such a binary and have a similar simple test to trigger the problem

00:22 <fche> hmmmm might have a simpler test, stand by

00:26 <fche> stap -e 'probe process("/usr/bin/nm").function("*").call { println(ppfunc(), " ", usymdata(uaddr())) }' -c nm

00:27 <fche> stap -e 'probe process.function("*").call { println(ppfunc(), " ", usymdata(uaddr())) }' -c php

00:27 <fche> vs -c nm

00:27 <fche> in the nm case, the names / addr-to-symbol lookups match

00:27 <fche> in the php case, they do not

00:51 <kerneltoast> noice

00:51 <fche> so trying to build php here to see How It's Made

01:13 <fche> https://paste.centos.org/view/4624bea3 <<< from the php.spec fedora build

01:13 <fche> -Wl,-zcommon-page-size=2097152 -Wl,-zmax-page-size=2097152 <<< i suspect these are responsible

02:06 <kerneltoast> fche, and the offset for the executable section in php is exactly 2097152 bytes (0x200000)

02:06 <fche> yes

02:07 <fche> huge page mmap optimization

02:07 <fche> because why not?

02:16 <kerneltoast> optimization freaks

02:17 <kerneltoast> no wonder we were hard pressed to find other binaries with the same issue

02:17 <fche> but at least that test case should serve to validate non-regression with your patch

02:17 <fche> too late tonight for me to play

02:17 <fche> but

02:18 <fche> at least there's a theory & prototype for test too

02:18 <kerneltoast> yay

17:45 <irker940> systemtap: sultan systemtap.git:master * release-4.4-118-gd1b554876 / runtime/sym.c runtime/task_finder_vma.c runtime/unwind.c runtime/vma.c: runtime: fix symbol lookups when the first section isn't executable

17:45 <irker940> systemtap: fche systemtap.git:master * release-4.4-119-g4641633a5 / testsuite/systemtap.base/large_page.c testsuite/systemtap.base/large_page.exp testsuite/systemtap.base/large_page.stp: testsuite: fix symbol lookups when the first section isn't executable

18:52 <kerneltoast> fche, nice

18:52 <fche> kerneltoast, the test case was not too complicated

18:54 <kerneltoast> the commit message looks like someone else wrote it though :P

18:54 <fche> :)

18:55 <kerneltoast> i guess it wasn't correct in its original form

18:55 <kerneltoast> since the issue turned out to be weirder

18:55 <fche> well not sure how much this impacts

18:55 <fche> I'm not sure it's ONLY Php

18:55 <fche> so asked serhei to keep an eye out for testsuite regressions across our buildbot farm

18:56 <serhei> yep

18:57 <kerneltoast> noice, i just went to sleep and everything handled itself

19:00 <fche> well let that be a lesson to you

19:00 <fche> :)