htop-dev
Backtrace screen (improvements over #1270)
This branch is experimental and related to #1270 (the backtrace screen feature).
I've written and improved the configure script so that it can check libunwind-ptrace and libiberty for the backtrace feature proposed in #1270.
The changes come with two parts:
The first part can be reviewed and cherry-picked into main early. It renames the configure option --enable-unwind to --with-libunwind to better reflect it's purpose. The old option name is preserved for compatibility but will trigger warnings when used.
The second part consists of several commits that add the new configure options --enable-backtrace and --enable-demangling and the checking code of libunwind-ptrace and libiberty. The code might look large and complicated, but I've tried a lot on the usability and correctness of the check. For example this libunwind-ptrace check can work with and without pkg-config, and I tried to ensure the cplus_demangle() function has a correct prototype.
The libunwind-ptrace and libiberty libraries can be detected both in Linux and in FreeBSD. However, I haven't ported the backtrace screen code from @MrCirdo to ensure they really build, especially in FreeBSD.
Can you note, which commits for the first vs. second part? I assume the first commit ("Rename *" for the first and the remaining 4 later?
I think we can also do this all at once. But I'm ope on that front.
Can you note, which commits for the first vs. second part? I assume the first commit ("Rename *" for the first and the remaining 4 later?
Yes, the first commit is the option rename, and the remaining 4 commits are the new feature / configure options.
The reason I suggest the rename is that --enable-backtrace=unwind-ptrace will depend on the --with-libunwind option and it's hard to split the two apart. That means the --enable-backtrace=unwind-ptrace --without-libunwind combination will being you an error.
Do we have alternative backends for backtracing/demangling besides unwind-ptrace and iberty? Given there's both an unwind implementation in LLVM and GCC, what else are sensible alternatives that warrent implementation of the --enable-backtrace switch as --enable-backtrace=unwind (if I saw that correctly in the source)?
Do we have alternative backends for backtracing/demangling besides unwind-ptrace and iberty? Given there's both an unwind implementation in LLVM and GCC, what else are sensible alternatives that warrent implementation of the
--enable-backtraceswitch as--enable-backtrace=unwind(if I saw that correctly in the source)?
Well, I don't know what other libraries are possible for the backtrace feature, but I leave room for those new backends.
For the demangling function, I can see libdemangle from Solaris / Sun Studio as a possible alternative, but I didn't check that yet. It's better for @MrCirdo 's code (#1270) get merged first before considering alternatives.
NP. No need to decide on all the possible backends and variants now. That's something we can leave open for the first implementation. Priority is getting things work; make them flexible and fast is the next step. No need to over-engineer things from the get-go. I just wanted to evaluate if there's a reasonable need for allowing the backends for backtraces and demangling to be replaced.
I would like to hand this branch over to @MrCirdo. I think I have done with this. After this is handed over, I have some comments on @MrCirdo 's code, things I suggest that can be written better.
I think I have done with this.
Great! Perfect! Thank you very much!
After this is handed over, I have some comments on @MrCirdo 's code, things I suggest that can be written better.
With pleasure!
Wait, let’s get on the same page @Explorer09. My idea was to split my PR into parts. The first part, which is presented here, involves adding a better configuration to my original PR. The second part is the behavior of the backtrace screen. And here you split both (Deeply apologize if I explain my idea very badly). If I understand well what @BenBE said, this PR would serve as a good base for #1270. So my question is : Do I have to close #1270 and continue my work on this one? I'm confused :smile:
My primary concern about supporting the BSD platform (FreeBSD, NetBSD, macOS, etc) is that I don't know if ptrace(2) has the same behavior everywhere. (I suppose yes, but I've never used a BSD platform). So, reassure me, @Explorer09, that's the case?
NB : Sorry if I take time to answer because I need to do some preparation for a coding interview.
My primary concern about supporting the BSD platform (FreeBSD, NetBSD, macOS, etc) is that I don't know if
ptrace(2)has the same behavior everywhere. (I suppose yes, but I've never used a BSD platform). So, reassure me, @Explorer09, that's the case?
I didn't test running the code on BSD yet. The only thing I've tested is building htop with libunwind-ptrace and libiberty on FreeBSD on a CI server. I've read the man page of ptrace(2) for FreeBSD and got the equivalent keywords (PT_ATTACH and PT_DETACH), and those are what I've done.
My aim is to make it buildable in Linux and FreeBSD; other OSes are too difficult and I would expect libunwind port to those platforms first before we try making our backtrace feature work there.
I think I have done with this.
Great! Perfect! Thank you very much!
I.e. no further changes from @Explorer09 unless needed/requested. And possibly rebases onto main maybe.
After this is handed over, I have some comments on @MrCirdo 's code, things I suggest that can be written better.
With pleasure!
Wait, let’s get on the same page @Explorer09. My idea was to split my PR into parts. The first part, which is presented here, involves adding a better configuration to my original PR. The second part is the behavior of the backtrace screen. And here you split both (Deeply apologize if I explain my idea very badly). If I understand well what @BenBE said, this PR would serve as a good base for #1270. So my question is : Do I have to close #1270 and continue my work on this one? I'm confused :smile:
I think this PR will likely stay as is; i.e. no major changes.
My primary concern about supporting the BSD platform (FreeBSD, NetBSD, macOS, etc) is that I don't know if
ptrace(2)has the same behavior everywhere. (I suppose yes, but I've never used a BSD platform). So, reassure me, @Explorer09, that's the case?
You can ask @fraggerfox regarding NetBSD details if necessary.
NB : Sorry if I take time to answer because I need to do some preparation for a coding interview.
NP.
My primary concern about supporting the BSD platform (FreeBSD, NetBSD, macOS, etc) is that I don't know if
ptrace(2)has the same behavior everywhere. (I suppose yes, but I've never used a BSD platform). So, reassure me, @Explorer09, that's the case?You can ask @fraggerfox regarding NetBSD details if necessary.
The libunwind README says its supported operating systems are Linux, FreeBSD, Solaris, QNX and HP-UX (partially). NetBSD is not included.
For Solaris, there's no pre-built binary package for libunwind so testing on it would be difficult. QNX and HP-UX are out of htop's scope. So there remains Linux and FreeBSD, which are what I tried to make htop's backtrace work for.
Wait, let’s get on the same page @Explorer09. My idea was to split my PR into parts. The first part, which is presented here, involves adding a better configuration to my original PR. The second part is the behavior of the backtrace screen. And here you split both (Deeply apologize if I explain my idea very badly). If I understand well what @BenBE said, this PR would serve as a good base for #1270. So my question is : Do I have to close #1270 and continue my work on this one? I'm confused 😄
I think this PR will likely stay as is; i.e. no major changes.
Perfect! :smile: I closed the first one.
Can I push on your branch @Explorer09 to fix the problem you emphasized?
Wait, let’s get on the same page @Explorer09. My idea was to split my PR into parts. The first part, which is presented here, involves adding a better configuration to my original PR. The second part is the behavior of the backtrace screen. And here you split both (Deeply apologize if I explain my idea very badly). If I understand well what @BenBE said, this PR would serve as a good base for #1270. So my question is : Do I have to close #1270 and continue my work on this one? I'm confused 😄
I think this PR will likely stay as is; i.e. no major changes.
Perfect! 😄 I closed the first one.
Can I push on your branch @Explorer09 to fix the problem you emphasized?
I have enabled push access for this particular branch configure-enable-backtrace, so feel free to push.