Hi Omar,
On Mon, 2020-03-23 at 01:55 -0700, Omar Sandoval wrote:
> > That is a really nice testcase. If we tweak it a little (so all
> > segments have the same load address) then it compresses to just 188
> > bytes with bzip2. Would you mind, and give your signed-off-by, for
> > adding the attache
On Sun, Mar 22, 2020 at 11:40:34PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Sat, 2020-03-21 at 11:21 -0700, Omar Sandoval wrote:
> > I encountered this in drgn on a vmcore for a large server created by
> > makedumpfile,
>
> That makes sense since [vm]cores contain lots of segments.
>
> > b
Hi Omar,
On Sat, 2020-03-21 at 11:21 -0700, Omar Sandoval wrote:
> I encountered this in drgn on a vmcore for a large server created by
> makedumpfile,
That makes sense since [vm]cores contain lots of segments.
> but I was able to put together a minimal reproducer.
> Generate the ELF file with
On Sat, Mar 21, 2020 at 01:30:55AM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Wed, Mar 18, 2020 at 01:18:51PM -0700, Omar Sandoval wrote:
> > __elf_getphdrnum_rdlock() handles PN_XNUM by getting sh_info from
> > elf->state.elf{32,64}.scns.data[0].shdr.e{32,64}. However, that is only
> > a cache
Hi Omar,
On Wed, Mar 18, 2020 at 01:18:51PM -0700, Omar Sandoval wrote:
> __elf_getphdrnum_rdlock() handles PN_XNUM by getting sh_info from
> elf->state.elf{32,64}.scns.data[0].shdr.e{32,64}. However, that is only
> a cache that may or may not have been populated by elf_begin() or
> elf{32,64}_get
From: Omar Sandoval
__elf_getphdrnum_rdlock() handles PN_XNUM by getting sh_info from
elf->state.elf{32,64}.scns.data[0].shdr.e{32,64}. However, that is only
a cache that may or may not have been populated by elf_begin() or
elf{32,64}_getshdr(); if it hasn't been cached yet, elf_getphdrnum()
retu
