[illumos-gate] 15642 MPI headers could be shared among drivers -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 15644 want lmrc driver for Aero and Ventura generations of MegaRAID SAS controllers -- Hans Rosenfeld <rosenfeld⊙gho>

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?

jperkin: no.. #13577 / #13578

at least if it's kernel stuff

i'm not sure offhand how userland bits are handled

hmm, but that doesn't include the types in Robert's demo of dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace

yeh this is userland

somehow it is so that every time I need to dtrace something in userland, there is no ctf :D

ok, looks like gstrip is taking something out even though SUNW_ctf is still there, binary pre-strip works fine

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.

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

```

oops sorry for the typo

I thought strip -x was the thing that removed say dwarf without doing other stuff.

the -l I don't really understand, it's the same size but removes the type somehow

My guess is that we're not renumbering the sh_link section appropriately somehow.

But dunno.

added note for gstrip, can't find anything other options to preserve data and it still doesn't work

I'll take a look at strip

jperkin: I might suggest going at it from why the ctf tools can't find something there.

I guess both would be useful, wouldn't be ideal to force a new platform to get the fix (unless I misunderstand that approach)

I only meant as a way to understand what's failing.

ok

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.

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

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..

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

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

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.

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).

hmm, haven't seen that and we've had 2.41 for a little while, will keep an eye out though, thanks.

Perhaps you aren't building with --with-dtrace then, as that's the bit which is affected.

ah yeh, that was removed a while back due to constant fallout with it requiring python2

Maybe, really, "nobody is using it" :)

yeh I'd be surprised at this point

jperkin: Would support for a strip -o help you?

rmustacc: it would be a number of years before I could rely on it, but it would probably be useful regardless

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.

yeh, I think generally an -o option is good for tools that produce modified binaries