jeez... > 24 hours for opengrok to index illumos-gate, freebsd, and linux

jbk any data on how long took each?

[illumos-gate] 16258 telnet: parameter defaults to 'int' -- Toomas Soome <tsoome⊙mc>

possibly dumb question, possibly asked at the wrong time: why don't we install ctfconvert and ctfmerge to /usr/bin ?

Mostly because I'm a bum.

(discovered yesterday that the python support in pstack requires python to be built with CTF to get argument counts, so I started opening that can of worms...)

pretty sure python is a can of snakes, not worms

fun: paste.ec/paste/EnAv6QjR#QTXYkO160jEbnqvZyULZuv8wY+KFALDgzO6+ze4R8qT

ah, next can of worms: oi python is built with feedback-directed optimization which splits code for function "foo" into "foo" and "foo.cold" (and the latter doesn't get ctf argument info...)

sommerfeld: Are you taking advantage of the ctfconvert at the end of the link?

uh, probably not?

Oh.

Let me say it differently, are you trying to use ctfmerge?

(I tweaked the python makefiles to insert ctfconvert / ctfmerge like the way we build illumos-gate)

Ah, so we added the ability to just do a single ctfconvert of the resulting binary.

In OmniOS we do a batch ctfconvert at the end, on DESTDIR

(don't know if that approach helps you)

You don't need to do the old merge path.

So mentioning that in case those symbols exist for some reason and have dwarf but aren't getting filled in.

had no idea that had any chance of working!

Oh, sorry.

I redid a bunch of this a while back.

The goal is you shouldn't need ctfmerge except for exceptions.

But I never went back and changed all the makefiles in gate.

so build with -g -gdwarf-2 -gstrict-dwarf -msave-args, then at the very end ctfconvert all the delivered executables and shared libraries?

Or -gdwarf-4 should work.

But yeah.

gate does gdwarf-2 still

However, if they don't have dwarf for the .cold variants not a ton I can do immediately.

I know.

Again, I'm a bum.

The tools and test suite generally work with gcc/clang and dwarf4.

But it shouldn't make much of a difference what you're doing at your end.

trying to get the pstack python support working again. multiple complications (not least of which is that they renamed some functions and juggled argument order within python that will require changes in both pstack and the python debug helper)

Yeah, I was following.

I just meant -gdwarf-2/dwarf-4 may or may not make a ton of difference is all.

okay, got something that looks like a python-annotated stack trace

(python 3.9, built without the .cold stuff, with a hacked up pstack and libpython3.9_db

but I think I can fix it "correctly" w/o too much effort.

so (1) need CTF for python; (2) need a patch to libpython39_db.c to look for the correct libpython symbol, and (3) need pstack to pass argument 1 rather than argument 0 because that's where python puts its python frame now.

(3) is an interface change so I think I need to rename the helper function to signal which argument to pass..

That's really nice!

I filed illumos.org/issues/16272

→ BUG 16272: python support in pstack should work again (New)