On Thu, Dec 21, 2017 at 02:48:15PM +0100, Ulf Hermann wrote:
> > yes, but the original code really was not correct. The attached patch
> > fixes it by adding an explicit sec_idx field to the Dwarf_CU struct
> > that is set whenever a struct Dwarf_CU is created, so that we never
> > have to guess.
>
yes, but the original code really was not correct. The attached patch
fixes it by adding an explicit sec_idx field to the Dwarf_CU struct
that is set whenever a struct Dwarf_CU is created, so that we never
have to guess.
This patch combined with the overflow fix makes all testcases PASS.
Looks
On Thu, 2017-12-14 at 14:53 +0100, Ulf Hermann wrote:
> On 12/14/2017 02:51 PM, Mark Wielaard wrote:
> > This is clever and indeed cu_sec_idx () is not generic enough.
> > But this is also somewhat inefficient. I am working on DWARF5 support
> > and there a CU can come from even more different sect
On 12/14/2017 02:51 PM, Mark Wielaard wrote:
> This is clever and indeed cu_sec_idx () is not generic enough.
> But this is also somewhat inefficient. I am working on DWARF5 support
> and there a CU can come from even more different sections (or file). So
> I am changing Dwarf_CU to have an explici
On Fri, 2017-12-08 at 16:06 +0100, Ulf Hermann wrote:
> Apparently CUs can appear in other sections than IDX_debug_info and
> IDX_types. Rather than relying on the indirect indication provided by
> type_offset we compare the addresses directly to figure out which section
> a given CU belongs to.
T
Apparently CUs can appear in other sections than IDX_debug_info and
IDX_types. Rather than relying on the indirect indication provided by
type_offset we compare the addresses directly to figure out which section
a given CU belongs to.
This fixes the dwarf-getmacros test.
(Signed-off instead of C
