Hi Paul,
On Wed, 2020-10-28 at 00:40 -0400, Paul Smith wrote:
> On Tue, 2020-10-27 at 23:23 +0100, Mark Wielaard wrote:
> > Do you have the generated core files somehwere so others can look
> > at
> > them? How exactly are you testing the build-id notes are there?
>
> I don't have one to publish
On Tue, 2020-10-27 at 23:23 +0100, Mark Wielaard wrote:
> Do you have the generated core files somehwere so others can look at
> them? How exactly are you testing the build-id notes are there?
I don't have one to publish but I can create one. That's a good idea
anyway as it will be simpler to deb
Hi Paul,
On Tue, Oct 27, 2020 at 04:20:51PM -0400, Paul Smith wrote:
> On Tue, 2020-10-27 at 15:39 +0100, Mark Wielaard wrote:
> > The basic idea behind getting buildids into core files is that they
> > (the GNU ELF notes) are at the start of the file in the first page
> > that is dumped (together
Thanks Mark,
On Tue, 2020-10-27 at 15:39 +0100, Mark Wielaard wrote:
> The basic idea behind getting buildids into core files is that they
> (the GNU ELF notes) are at the start of the file in the first page
> that is dumped (together with the phdrs) in the core file so when
> core file consumers
Hi Paul,
On Mon, 2020-10-26 at 03:06 -0400, Paul Smith wrote:
> We use this for various reasons rather than relying on the Linux
> kernel
> coredumper and it's worked well for us for many years now. However, I
> would like to start using build IDs in our shared libs and binaries and
> to take bes
Hi all;
I'm maintaining a fork of the old Google coredumper code:
Original: https://github.com/anatol/google-coredumper
My fork: https://github.com/madscientist/google-coredumper
We use this for various reasons rather than relying on the Linux kernel
coredumper and it's worked well for us for ma
