* Minimal FDE
@ 2004-08-30 20:03 Yaakov Yaari
2004-08-30 20:57 ` Richard Henderson
0 siblings, 1 reply; 7+ messages in thread
From: Yaakov Yaari @ 2004-08-30 20:03 UTC (permalink / raw)
To: gcc
Hello,
Assuming executables are manipulated by splitting and resizing of
functions.
Here is a simplified case:
------------ before ---------
func1
-------
func2
------------ after -----------
func1_1
br func1_2
----------
func2
----------
func1_2
----------
Exception handling poses a problem. If func1 is referred in the .eh_frame,
we need to resize its FDE range to the size of func1_1, and create is new
FDE for func1_2.
Considering FDE formation, it consists of a header (size, CIE pointer, and
function address and size), followed by a sequence of (DWARF) instructions.
How critical are these instructions to the unwinding process?
Is there some minimal/simplified set of instructions that will allow
exceptions to be properly caught?
Regards,
Yaakov
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Minimal FDE
2004-08-30 20:03 Minimal FDE Yaakov Yaari
@ 2004-08-30 20:57 ` Richard Henderson
2004-09-01 4:22 ` Alan Modra
0 siblings, 1 reply; 7+ messages in thread
From: Richard Henderson @ 2004-08-30 20:57 UTC (permalink / raw)
To: Yaakov Yaari; +Cc: gcc
On Mon, Aug 30, 2004 at 09:38:10PM +0300, Yaakov Yaari wrote:
> How critical are these instructions to the unwinding process?
Very.
> Is there some minimal/simplified set of instructions that will allow
> exceptions to be properly caught?
No.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Minimal FDE
2004-08-30 20:57 ` Richard Henderson
@ 2004-09-01 4:22 ` Alan Modra
2004-09-01 6:51 ` Yaakov Yaari
0 siblings, 1 reply; 7+ messages in thread
From: Alan Modra @ 2004-09-01 4:22 UTC (permalink / raw)
To: Yaakov Yaari, gcc
On Mon, Aug 30, 2004 at 01:52:58PM -0700, Richard Henderson wrote:
> On Mon, Aug 30, 2004 at 09:38:10PM +0300, Yaakov Yaari wrote:
> > How critical are these instructions to the unwinding process?
>
> Very.
>
> > Is there some minimal/simplified set of instructions that will allow
> > exceptions to be properly caught?
>
> No.
Depending on exactly where you split the function, you probably just
need to copy the existing FDE, removing the address advances. So, if
you only split after the prologue, and given a typical existing FDE
like:
DW_CFA_advance_loc: 4
DW_CFA_def_cfa_offset: 48
DW_CFA_advance_loc: 12
DW_CFA_offset: r30 at cfa-8
DW_CFA_advance_loc: 16
DW_CFA_offset: r25 at cfa-28
DW_CFA_offset_extended_sf: r65 at cfa+4
DW_CFA_offset: r24 at cfa-32
DW_CFA_advance_loc: 12
DW_CFA_offset: r26 at cfa-24
DW_CFA_advance_loc: 12
DW_CFA_offset: r27 at cfa-20
DW_CFA_advance_loc: 16
DW_CFA_offset: r29 at cfa-12
DW_CFA_offset: r28 at cfa-16
DW_CFA_advance_loc: 8
DW_CFA_offset: r31 at cfa-4
Then, for the piece of function you split out, you'd write
DW_CFA_def_cfa_offset: 48
DW_CFA_offset: r30 at cfa-8
DW_CFA_offset: r25 at cfa-28
DW_CFA_offset_extended_sf: r65 at cfa+4
DW_CFA_offset: r24 at cfa-32
DW_CFA_offset: r26 at cfa-24
DW_CFA_offset: r27 at cfa-20
DW_CFA_offset: r29 at cfa-12
DW_CFA_offset: r28 at cfa-16
DW_CFA_offset: r31 at cfa-4
The tedious side of this is writing a DWARF2 interpreter to parse the
existing FDE, but I guess you can find a working example in the gcc
sources. ;-) It's probably not a good idea to try to write an
interpreter that just handles the minimal set of DWARF2 opcodes used by
a particular gcc target; I've had one request from someone inside IBM
for help writing .eh_frame info for some assembler code. The required
.eh_frame info looked quite different to that generated by gcc.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Minimal FDE
2004-09-01 4:22 ` Alan Modra
@ 2004-09-01 6:51 ` Yaakov Yaari
2004-09-01 7:26 ` Alan Modra
0 siblings, 1 reply; 7+ messages in thread
From: Yaakov Yaari @ 2004-09-01 6:51 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc
Alan Modra <amodra@bigpond.net.au> wrote on 01/09/2004 07:22:03:
> On Mon, Aug 30, 2004 at 01:52:58PM -0700, Richard Henderson wrote:
> > On Mon, Aug 30, 2004 at 09:38:10PM +0300, Yaakov Yaari wrote:
> > > How critical are these instructions to the unwinding process?
> >
> > Very.
> >
> > > Is there some minimal/simplified set of instructions that will allow
> > > exceptions to be properly caught?
> >
> > No.
>
> Depending on exactly where you split the function, you probably just
> need to copy the existing FDE, removing the address advances. So, if
> you only split after the prologue, and given a typical existing FDE
> like:
>
> DW_CFA_advance_loc: 4
> DW_CFA_def_cfa_offset: 48
> DW_CFA_advance_loc: 12
> DW_CFA_offset: r30 at cfa-8
> DW_CFA_advance_loc: 16
> DW_CFA_offset: r25 at cfa-28
> DW_CFA_offset_extended_sf: r65 at cfa+4
> DW_CFA_offset: r24 at cfa-32
> DW_CFA_advance_loc: 12
> DW_CFA_offset: r26 at cfa-24
> DW_CFA_advance_loc: 12
> DW_CFA_offset: r27 at cfa-20
> DW_CFA_advance_loc: 16
> DW_CFA_offset: r29 at cfa-12
> DW_CFA_offset: r28 at cfa-16
> DW_CFA_advance_loc: 8
> DW_CFA_offset: r31 at cfa-4
>
> Then, for the piece of function you split out, you'd write
>
> DW_CFA_def_cfa_offset: 48
> DW_CFA_offset: r30 at cfa-8
> DW_CFA_offset: r25 at cfa-28
> DW_CFA_offset_extended_sf: r65 at cfa+4
> DW_CFA_offset: r24 at cfa-32
> DW_CFA_offset: r26 at cfa-24
> DW_CFA_offset: r27 at cfa-20
> DW_CFA_offset: r29 at cfa-12
> DW_CFA_offset: r28 at cfa-16
> DW_CFA_offset: r31 at cfa-4
>
> The tedious side of this is writing a DWARF2 interpreter to parse the
> existing FDE, but I guess you can find a working example in the gcc
> sources. ;-) It's probably not a good idea to try to write an
> interpreter that just handles the minimal set of DWARF2 opcodes used by
> a particular gcc target; I've had one request from someone inside IBM
> for help writing .eh_frame info for some assembler code. The required
> .eh_frame info looked quite different to that generated by gcc.
>
> --
> Alan Modra
> IBM OzLabs - Linux Technology Centre
I also thought about replicating the original FDE for each disjoint chunk
of the function. However I assumed that the specified nonvolatile registers
are restored by accessing the stack directly, without going through the
prolog, essentially, ignoring the advance instructions.
If advance instructions can be removed, as you suggest, it means the
interpreter does not need the actual prolog instructions in order to have a
proper restore. In this case why can't we just leave them and get the same
effect?
Yaakov Yaari
IBM HRL
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Minimal FDE
2004-09-01 6:51 ` Yaakov Yaari
@ 2004-09-01 7:26 ` Alan Modra
2004-09-01 7:59 ` Yaakov Yaari
0 siblings, 1 reply; 7+ messages in thread
From: Alan Modra @ 2004-09-01 7:26 UTC (permalink / raw)
To: Yaakov Yaari; +Cc: gcc
On Wed, Sep 01, 2004 at 09:51:04AM +0300, Yaakov Yaari wrote:
> If advance instructions can be removed, as you suggest, it means the
> interpreter does not need the actual prolog instructions in order to have a
> proper restore.
As you say, the gcc unwinder does not need to look at the prologue.
> In this case why can't we just leave them and get the same
> effect?
Because they qualify the pc address range. The eh_frame info is really
a little program that says where certain registers get saved, and how
the stack frame changes. The location changing opcodes say that
following actions haven't happened until the specified pc is reached.
Taking a real example from libc, these two instructions:
0000000000046238 <.__gcc_personality_v0>:
46238: 7c 08 02 a6 mflr r0
4623c: fb 81 ff e0 std r28,-32(r1)
have corresponding eh_frame info:
00000040 00000034 00000044 FDE cie=00000000 pc=00046238..000462f0
DW_CFA_advance_loc: 8 to 00046240
DW_CFA_offset: r28 at cfa-32
So the FDE is valid for pc's in the range 46238..462f0, but told to
unwind starting from a pc of 46238 or 4623c, the unwinder will know
that r28 should not be read from the stack frame..
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Minimal FDE
2004-09-01 7:26 ` Alan Modra
@ 2004-09-01 7:59 ` Yaakov Yaari
2004-09-01 8:27 ` Alan Modra
0 siblings, 1 reply; 7+ messages in thread
From: Yaakov Yaari @ 2004-09-01 7:59 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc
Alan Modra <amodra@bigpond.net.au> wrote on 01/09/2004 10:26:48:
...
> 0000000000046238 <.__gcc_personality_v0>:
> 46238: 7c 08 02 a6 mflr r0
> 4623c: fb 81 ff e0 std r28,-32(r1)
>
> have corresponding eh_frame info:
>
> 00000040 00000034 00000044 FDE cie=00000000 pc=00046238..000462f0
> DW_CFA_advance_loc: 8 to 00046240
> DW_CFA_offset: r28 at cfa-32
>
> So the FDE is valid for pc's in the range 46238..462f0, but told to
> unwind starting from a pc of 46238 or 4623c, the unwinder will know
> that r28 should not be read from the stack frame..
My assumption is that when readelf -wf interprets the FDE and prints, "
DW_CFA_advance_loc: 8 to 00046240", it does so because initially the PC is
at 46238, and it encounters an "advance 8" instruction. The location 46240
is not in the DWARF instruction. Thus, a replicated FDE, for some disjoint
chunk (00050000..0005008) of this function, would have the header part of
the FDE indicate that range, encoded as 0x50000, 0x8, and the rest of the
FDE replicated as is. Given that, the readelf will interpret that FDE
something like..
00000040 00000034 00000044 FDE cie=00000000 pc=00050000..50008
DW_CFA_advance_loc: 8 to 0005008
DW_CFA_offset: r28 at cfa-32
Am I wrong?
Yaakov Yaari
IBM HRL
I am probably wrong in my assumptions on the DWARF code
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Minimal FDE
2004-09-01 7:59 ` Yaakov Yaari
@ 2004-09-01 8:27 ` Alan Modra
0 siblings, 0 replies; 7+ messages in thread
From: Alan Modra @ 2004-09-01 8:27 UTC (permalink / raw)
To: Yaakov Yaari; +Cc: gcc
On Wed, Sep 01, 2004 at 10:59:05AM +0300, Yaakov Yaari wrote:
> Alan Modra <amodra@bigpond.net.au> wrote on 01/09/2004 10:26:48:
> > 0000000000046238 <.__gcc_personality_v0>:
> > 46238: 7c 08 02 a6 mflr r0
> > 4623c: fb 81 ff e0 std r28,-32(r1)
> >
> > have corresponding eh_frame info:
> >
> > 00000040 00000034 00000044 FDE cie=00000000 pc=00046238..000462f0
> > DW_CFA_advance_loc: 8 to 00046240
> > DW_CFA_offset: r28 at cfa-32
> >
> > So the FDE is valid for pc's in the range 46238..462f0, but told to
> > unwind starting from a pc of 46238 or 4623c, the unwinder will know
> > that r28 should not be read from the stack frame..
>
> My assumption is that when readelf -wf interprets the FDE and prints, "
> DW_CFA_advance_loc: 8 to 00046240", it does so because initially the PC is
> at 46238, and it encounters an "advance 8" instruction. The location 46240
Yes.
> is not in the DWARF instruction. Thus, a replicated FDE, for some disjoint
> chunk (00050000..0005008) of this function, would have the header part of
> the FDE indicate that range, encoded as 0x50000, 0x8, and the rest of the
> FDE replicated as is. Given that, the readelf will interpret that FDE
> something like..
> 00000040 00000034 00000044 FDE cie=00000000 pc=00050000..50008
> DW_CFA_advance_loc: 8 to 0005008
> DW_CFA_offset: r28 at cfa-32
Yes, that's what you would get if you replicated the FDE, and only
changed the range. But as I said before, copying the advance_loc is
wrong. Complete nonsense for this example of a two insn chunk. :)
The advance_loc says nothing happens in the chunk until you reach
address 5008, but that's outside the chunk!
Given a chunk pulled out of the body of the function somewhere, you want
to say that all register saving and stack growth have already happened
at the start of the chunk, _not_ that various things happen as we
execute the chunk.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-09-01 8:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-30 20:03 Minimal FDE Yaakov Yaari
2004-08-30 20:57 ` Richard Henderson
2004-09-01 4:22 ` Alan Modra
2004-09-01 6:51 ` Yaakov Yaari
2004-09-01 7:26 ` Alan Modra
2004-09-01 7:59 ` Yaakov Yaari
2004-09-01 8:27 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).