On 10/8/24 15:16, Ka Ho Ng wrote:
On Tue, Oct 8, 2024 at 4:16 PM Cy Schubert <cy.schub...@cschubert.com>
wrote:
In message <alpine.bsf.2.00.2410082251130.15...@woozle.rinet.ru>, Dmitry
Morozo
vsky writes:
On Tue, 8 Oct 2024, Shawn Webb wrote:
On Tue, Oct 08, 2024 at 07:40:31PM UTC, Ka Ho Ng wrote:
The branch main has been updated by khng:
URL:
https://cgit.FreeBSD.org/src/commit/?id=50c64df2a1739dca84c0e3bc795b
70e5991b7010
commit 50c64df2a1739dca84c0e3bc795b70e5991b7010
Author: Ka Ho Ng <k...@freebsd.org>
AuthorDate: 2024-10-08 19:40:20 +0000
Commit: Ka Ho Ng <k...@freebsd.org>
CommitDate: 2024-10-08 19:40:20 +0000
Revert "libkldelf: add a private library for kernel/kld-related
ELF p
arsing"
This reverts commit 0a2cfd653e86ac41c4e6e32a449d133c0ee6d677.
Could you please explain why?
bapt@: Since this set of commits, incremental building of packages
fail!
Hmm. I didn't experience this in my poudriere here.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
It affects pkgbase users mainly, and the reason is rather due to the
linkage issue between the separated privatelib and kldxref resulting in
empty LINKER_SETs in the privatelib. I will recommit this once it's fixed.
One thing I would still like to understand, btw, is your use case for
having the separate library? I think you plan to teach libkvm about
kernel modules so it can resolve symbols defined in kernel modules when
examining a vmcore? However, I'm curious why you need that functionality
in libkvm itself? That is, many of the problems you have to solve (e.g.
finding the separate debug files for kernel modules in /usr/lib/debug
so that you can parse the symbol table) are already handled in existing
debuggers like gdb and lldb. It's not clear to me that teaching libkvm
about kernel modules in crashdumps is the right way to solve the problem
you are solving vs using a debugger directly?
--
John Baldwin
