09:43:30 [illumos-gate] 15642 MPI headers could be shared among drivers -- Hans Rosenfeld 09:43:31 [illumos-gate] 15644 want lmrc driver for Aero and Ventura generations of MegaRAID SAS controllers -- Hans Rosenfeld 11:52:25 hmm, I have binaries that are built with CTF and -msave-args, ctfdump shows what looks like all valid data, but DTrace lists "None" for all "Argument Types" instead of the correct types as I would expect. Am I missing something obvious? 13:11:22 jperkin: no.. #13577 / #13578 13:14:21 at least if it's kernel stuff 13:14:32 i'm not sure offhand how userland bits are handled 13:14:35 hmm, but that doesn't include the types in Robert's demo of http://dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace/ 13:14:45 yeh this is userland 14:20:18 somehow it is so that every time I need to dtrace something in userland, there is no ctf :D 14:22:32 ok, looks like gstrip is taking something out even though SUNW_ctf is still there, binary pre-strip works fine 14:58:53 jperkin: I expect that we need the linked symbol table in an sh_link section of the elf header and not having that is causing some consternation. I could probably help you look at something if that'd help. 15:01:27 I'm just going through various options to see if I can get anything stripped that preserves them, our strip(1) has no modes that keep them 15:02:04 ``` 15:02:20 oops sorry for the typo 15:07:17 I thought strip -x was the thing that removed say dwarf without doing other stuff. 15:07:52 https://gist.github.com/jperkin/eca867773bb52472fe263b4de88faeb7 15:08:25 the -l I don't really understand, it's the same size but removes the type somehow 15:10:14 My guess is that we're not renumbering the sh_link section appropriately somehow. 15:10:33 But dunno. 15:19:56 added note for gstrip, can't find anything other options to preserve data and it still doesn't work 15:21:15 I'll take a look at strip 15:40:04 jperkin: I might suggest going at it from why the ctf tools can't find something there. 15:54:14 I guess both would be useful, wouldn't be ideal to force a new platform to get the fix (unless I misunderstand that approach) 15:55:29 I only meant as a way to understand what's failing. 15:57:03 ok 15:58:40 If we understand what's missing to cause it to show an unknown type, that might speed up some of the surrounding strip debugging is all. 16:29:12 ah ok, so my initial diagnosis was wrong as with DTRACE_DEBUG enabled it shows that it's failing if the object has been renamed, if I move the stripped versions back to the original filename then dtrace works 16:36:00 in which case I just need to rewrite some of our strip handling and then everything should be good - sorry for the noise, I imagine most of you are already just using strip -x and not having this issue.. 17:02:38 strip -x is what the omnios build uses, definitely. I think we did find that gstrip caused some breakage in the past, or at least reduced debugability 17:19:02 yeh there was an issue with recent binutils, I should have switched to strip -x earlier, it's just that pkgsrc currently assumes that the strip program supports -o so I'll need to write a wrapper 17:26:14 Talking about recent binutils, objdump in 2.41 breaks the nodejs build. I don't know if that will affect you but thought I'd mention it. 17:26:55 We have patches in omnios for node 12-18 (and they've removed dtrace support in trunk now "nobody uses it" so the next version will be fine). 17:30:00 hmm, haven't seen that and we've had 2.41 for a little while, will keep an eye out though, thanks. 17:30:45 Perhaps you aren't building with --with-dtrace then, as that's the bit which is affected. 17:33:47 ah yeh, that was removed a while back due to constant fallout with it requiring python2 17:37:29 Maybe, really, "nobody is using it" :) 17:38:09 yeh I'd be surprised at this point 17:40:59 jperkin: Would support for a strip -o help you? 17:45:50 rmustacc: it would be a number of years before I could rely on it, but it would probably be useful regardless 17:46:42 I get that bringing back binaries is a challenge for the bulk build process, just want to make sure we're still taking action to improve things. 18:04:22 yeh, I think generally an -o option is good for tools that produce modified binaries