From: Omar Sandoval
dwfl_thread_getframes always frees the state before returning, so
dwfl_getthreads and getthread don't need to do it.
Signed-off-by: Omar Sandoval
---
libdwfl/ChangeLog| 6 ++
libdwfl/dwfl_frame.c | 18 +++---
2 files changed, 9 insertions(+
From: Omar Sandoval
thread->unwound is only used for set_initial_registers (via
dwfl_thread_state_registers, dwfl_thread_state_register_pc, and a
special case in core_set_initial_registers). At that point,
thread->unwound is always the initial frame, so there's no need to
update it a
From: Omar Sandoval
libdwfl can evaluate DWARF expressions in order to unwind the stack, but
this functionality isn't exposed to clients of the library. Now that the
pieces are in place, add dwfl_frame_eval_expr to provide this feature.
Signed-off-by: Omar Sandoval
---
libdw/Chan
From: Omar Sandoval
Hello,
While using the libdwfl stack unwinding interface for my debugger [1], I
found that it works great for getting the program counter at each stack
frame, but it's hard to do anything beyond that. This is an attempt to
expand the functionality by adding two main fea
From: Omar Sandoval
The next change will need to have the Dwarf_Frame readily available, so
rather than finding it again every time, let's cache it for reuse. The
CFI frame can also be useful to clients of libdwfl, so add
dwfl_frame_dwarf_frame to get it. Similarly, the Dwfl_Module is
From: Omar Sandoval
libdwfl has implementations of attaching to/detaching from threads and
unwinding stack traces. However, that functionality is only available
through the dwfl_thread_getframes interface, which isn't very flexible.
This adds two new functions, dwfl_attach_threa
On Tue, Oct 29, 2019 at 04:55:27PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > dwfl_thread_getframes always frees the state before returning, so
> > dwfl_getthreads and getthread don't need to do it.
&
On Wed, Oct 30, 2019 at 01:47:52PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > libdwfl has implementations of attaching to/detaching from threads
> > and
> > unwinding stack traces. However, that func
On Wed, Oct 30, 2019 at 02:04:42PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > The next change will need to have the Dwarf_Frame readily available, so
> > rather than finding it again every time, let's cache
On Wed, Oct 30, 2019 at 02:23:06PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > libdwfl can evaluate DWARF expressions in order to unwind the stack,
> > but this functionality isn't exposed to clients of the
On Thu, Oct 31, 2019 at 05:21:17PM +0100, Mark Wielaard wrote:
> On Wed, 2019-10-30 at 16:49 -0700, Omar Sandoval wrote:
> > On Wed, Oct 30, 2019 at 01:47:52PM +0100, Mark Wielaard wrote:
> > > Also, if we would adopt dwfl_attach_thread then I think it should take
> > >
From: Omar Sandoval
dwfl_report_segment() has some logic that detects when a segment is
contiguous with the previously reported segment, in which case it's
supposed to coalesce them. However, in this case, it actually returns
without updating the segment array at all. As far as I can tell,
From: Omar Sandoval
Hello,
This small series fixes a couple of issues I encountered when building
elfutils. Patch 1 fixes an issue when compiling with CFLAGS='-Wno-error
-O0'. Patch 2 gets rid of a warning.
Thanks!
Omar Sandoval (2):
configure: Fix -D_FORTIFY_SOURCE=2 check w
From: Omar Sandoval
elfutils is compiled with -Wimplicit-fallthrough=5, so the fallthrough
comment in i386_lex.c (generated by flex) doesn't prevent the implicit
fallthrough warning. Add -Wno-implicit-fallthrough to i386_lex_CFLAGS.
Signed-off-by: Omar Sandoval
---
libcpu/ChangeLog
From: Omar Sandoval
If CFLAGS contains -Wno-error, then the check for -D_FORTIFY_SOURCE=2
won't fail when appropriate. E.g., compiling with:
./configure CFLAGS='-Wno-error -O0' &&
Results in a flood of "_FORTIFY_SOURCE requires compiling with
optimization (-O)&
On Tue, Dec 10, 2019 at 05:28:19PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> dwfl_report_segment() has some logic that detects when a segment is
> contiguous with the previously reported segment, in which case it's
> supposed to coalesce them. However, in th
From: Omar Sandoval
Hello,
I recently encountered a bug that dwfl_addrmodule doesn't work correctly
for Linux kernel modules. This is because each section of a kernel
module is allocated independently, so sections from different kernel
modules may be intermixed. For example:
# cd /sys/mo
From: Omar Sandoval
Currently, the address ranges for segments reported with
dwfl_report_segment and modules are stored in the same sorted array.
This requires complicated logic in reify_segments for splitting up
existing segments and inserting into the table, which can have quadratic
runtime in
From: Omar Sandoval
dwfl_addrmodule matches a module if the address lies within low_addr and
high_addr. This is incorrect for relocatable files, particularly kernel
modules: sections of different modules can be intermingled within the
same range of addresses. Instead, we should index each
From: Omar Sandoval
Currently, __libdwfl_relocate_value doesn't distinguish between unloaded
sections and sections loaded at address zero. This has a few
consequences:
* relocate.c attempts relocation on unloaded sections when we don't have
anything meaningful to reloca
From: Omar Sandoval
dwfl_report_segment has some logic that detects when a segment is
contiguous with the previously reported segment, in which case it's
supposed to coalesce them. However, in this case, it actually returns
without updating the segment array at all. As far as I can tell,
On Thu, Dec 12, 2019 at 12:17:23PM +0100, Mark Wielaard wrote:
> On Wed, 2019-12-11 at 16:23 -0800, Omar Sandoval wrote:
> > This small series fixes a couple of issues I encountered when building
> > elfutils. Patch 1 fixes an issue when compiling with CFLAGS='-Wno-error
&g
On Wed, Dec 11, 2019 at 05:29:42PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Hello,
>
> I recently encountered a bug that dwfl_addrmodule doesn't work correctly
> for Linux kernel modules. This is because each section of a kernel
> module is allocated indep
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_ge
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}. How
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]cor
From: Omar Sandoval
Whenever we encounter an attribute with DW_FORM_indirect, we need to
read its true form from the DIE data. Then, we can continue normally.
This adds support to the most obvious places: __libdw_find_attr() and
dwarf_getattrs(). There may be more places that need to be updated
On Sat, May 01, 2021 at 05:59:31PM +0200, Mark Wielaard wrote:
> Hi Omar,
>
> On Fri, 2021-04-23 at 16:36 -0700, Omar Sandoval wrote:
> > Whenever we encounter an attribute with DW_FORM_indirect, we need to
> > read its true form from the DIE data. Then, we can continue no
On Sat, May 01, 2021 at 06:03:37PM +0200, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2021-05-01 at 17:59 +0200, Mark Wielaard wrote:
> > There is __libdw_form_val_compute_len which already handles
> > DW_FORM_indirect:
> >
> > case DW_FORM_indirect:
> > get_uleb128 (u128, valp, endp);
> >
From: Omar Sandoval
When read_addrs() was converted was converted from a nested function to
a normal function, there was a mistake in converting "buffer" from a
closure variable to a parameter: we are checking whether the pointer
argument is NULL, not whether the buffer itself is
On Wed, Jun 09, 2021 at 05:45:57PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> When read_addrs() was converted was converted from a nested function to
> a normal function, there was a mistake in converting "buffer" from a
> closure variable to a parameter: we
On Wed, Jun 09, 2021 at 09:59:06PM -0300, Érico Nogueira wrote:
> Hope you don't mind my nit, then :)
Thanks, that's what I get for sending patches out right before dinner...
> On Wed Jun 9, 2021 at 9:51 PM -03, Omar Sandoval wrote:
> > On Wed, Jun 09, 2021 at 05:45:57P
101 - 132 of 132 matches
Mail list logo
