> By saying that .debug_frame supports shrink wrapping, do you also mean that
> it supports the “two paths join with different register state” case? Which
> means it’s only a matter of the .cfi_xxx directives, and if I were to build
> the .debug_frame/.eh_frame section by hand I would be fine?
> On 24 Mar 2016, at 16:35, Cary Coutant wrote:
>
> It's fine to have different regions of code with different register
> save states, but it's a bad idea to have two paths join without
> compensation code at the end of one or both paths to match the states.
> For example, you could restore the
>> I’m working on a edu/research compiler that has yet to be equipped with
>> DWARF info. Unlike GCC/Clang/… it doesn’t have spill slots that are
>> “constant” within a procedure, i.e. may procedure code like this:
>>
>> …
>>
>> Is this supported by the DWARF .cfi_offset directives at all, and i
>
> On 19 Mar 2016, at 12:46, Jonas H. wrote:
>
> I’m working on a edu/research compiler that has yet to be equipped with DWARF
> info. Unlike GCC/Clang/… it doesn’t have spill slots that are “constant”
> within a procedure, i.e. may procedure code like this:
>
> …
>
> Is this supported by
> I have a question about the FDE encoding in eh_frame (and not dwarf_frame)
> tables.
>
> This document (I could not find a better description of eh_frame)
>
> http://www.airs.com/blog/archives/460
The official description of the .eh_frame section, with a description
of the augmentation string
Dear all
I have a question about the FDE encoding in eh_frame (and not dwarf_frame)
tables.
This document (I could not find a better description of eh_frame)
http://www.airs.com/blog/archives/460
states that:
"An FDE starts with the length and ID described above, and then continues
as foll
