19:11:51 <richlowe> danmcd: cxgbetool needs the duplicate static/nonstatic names fixed
19:12:41 <richlowe> danmcd: however, if you need to work out which is which, you'll find the static one is (obviously) local, and the non-static one global
19:12:51 <richlowe> danmcd: so you can look with elfdump -s, and compare to your address
19:13:10 <richlowe>       [48]  0x080559e5 0x000000a3  FUNC LOCL  D    0 .text          dump_block_regs
19:13:11 <richlowe>       [96]  0x08054aa8 0x000000a3  FUNC GLOB  D    1 .text          dump_block_regs
19:13:24 <danmcd> Yeah... elfdump -s is my friend, isn't it?  (And I think I managed to tease it out given where it dumped core and the disassembly vs. the C code).
19:13:44 <danmcd> Thank you for confirming my gut, however, that something Is Very Wrong there w.r.t. names.
19:19:20 <richlowe> I wonder how much it would suck to make check_rtime complain about this, it obviously should.
19:19:37 <richlowe> hadfl: you enjoy modifying 90's perl, right? :)
19:58:52 <jbk> heh.. that's on my list to replace
19:59:35 <jbk> i've almost got interface_check done (C replacement)... though I was also thinking find_elf, interface_check, and check_rtime could  just be combined into one program (w/ aliases and still produce all the output from all three)
19:59:59 <jbk> since right now basically you run find_elf, take it's output, run that into interface_check
20:00:02 <jbk> etc
20:00:45 <jbk> at least on my system (which I know is getting old) it'd knock off several minutes off the total nightly time
20:33:51 <sommerfeld> figuring out a way to parallelize it (so you can use more than one CPU on a task that is serialized at the end of the build) would also be clever..
20:52:51 <jbk> i haven't done the check_rtime bits, but at least for interface_check, the C version runs in 0.2s single threaded... but maybe the check_rtime bits might benefit
20:53:11 <jbk> i just need to finish validating some of the bits for interface_check before throwing it up for review...
20:54:05 <jbk> i've not been able to find any relevant standards that say how the ELF versioning bits are supposed to work, so I've been having to reverse engineer what pvs is doing, so that's taken longer to be sure i've captured it correctly
20:54:38 <jbk> (there's one more check I need to tweak, but if my suspicion is correct, I don't think it'll have a measureable change on the runtime)
20:56:21 <jbk> specifically, what is considered a 'top' version... the more obvious one is a version that nothing else references... however it appears that if the only thing referencing a version are all weak versions (I'm not really sure what the correct nomenclature would be here)
20:56:33 <jbk> that is also considered a top version
20:56:48 <jbk> but that's just from examination, i need to verify that is in fact the correct criteria
20:56:58 <jbk> err from observation
21:06:01 <jbk> find_elf was a couple of minutes IIRC
21:06:19 <jbk> and check_rtime is several minutes long
21:06:31 <jbk> from looking at some old data
21:10:26 <gitomat> [illumos-gate] 16871 lgrpplat.c: array subscript -1 is below array bounds -- Andy Fiddaman <illumos⊙fn>
21:14:47 <gitomat> [illumos-gate] 16005 Need RFC8106 definitions in icmp6.h -- Bill Sommerfeld <sommerfeld⊙ame>