public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Vsevolod Alekseyev" <sevaa@sprynet.com>
To: <binutils@sourceware.org>
Subject: Readelf bug?
Date: Wed, 1 Jun 2022 23:39:16 -0400	[thread overview]
Message-ID: <000501d87632$56c038b0$0440aa10$@sprynet.com> (raw)

I'm debugging a DWARF parser library. We are testing it against GNU readelf,
and we've found a discrepancy on the dump of the interpreted .eh_frame
section of a particular x86_64 ELF binary.

 

The binary's first FDE in .eh_frame has initial_location 0x1060, and the
following instructions:

 

DW_CFA_advance_loc 4                                # Move PC by 4

DW_CFA_undefined 16                                 # Change the rule for
R16 to undefined

 

The linked CIE marks R16 as the return address, and has the following
instructions:

 

DW_CFA_def_cfa 7, 8                     # CFA is at R7+8

DW_CFA_offset 16, 1                      # Set the rule for R16 to
[CFA+1*data_aligment_factor])

 

The GNU readelf, if executed with --debug-dump=frames-interp, dumps the FDE
as follows:

 

00000018 0000000000000014 0000001c FDE cie=00000000
pc=0000000000001060..0000000000001086

     LOC           CFA      ra    

0000000000001060 rsp+8    u     

0000000000001064 rsp+8    u

 

Meanwhile, the alternative parser thinks that at the range [0x1060-0x1064),
the rule for RA/R16 should be as inherited from the CIE, and it goes c-8.

 

I've debugged readelf (the latest master, as of 06/01/22), to that point.
There are two passes over the FDE instructions: one starting on
dwarf.c:9296, the other starting at dwarf.c:9442. On the first pass, when
DW_CFA_undefined is encountered, there is the following case statement:

 

READ_ULEB (reg, start, block_end);

if (frame_need_space (fc, reg) >= 0)

    fc->col_type[reg] = DW_CFA_undefined;

break;

 

If I understand correctly, the intended purpose of the first pass is to
allocate enough memory in the fc->col_type and fc->col_offset arrays, and
the logic of this operator's handling was meant to be: if this register was
not mentioned before, allocate space for it, and reset its rule to
undefined. HOWEVER, if the register WAS mentioned before (e. g. in the CIE),
frame_need_space() returns 0, and the if() body executes anyway, and resets
the rule for the register to undefined, erasing the initial state as
specified by the CIE.

 

I think the if statement should go, instead, "if (frame_need_space (fc, reg)
> 0)". Same for other register-rule-type operators on the first pass.

 

The binary can be seen at
https://github.com/eliben/pyelftools/issues/409#issuecomment-1136720254

 

I'd submit a Bugzilla ticket, but registration is closed.

 

Thank you!

 


                 reply	other threads:[~2022-06-02  3:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000501d87632$56c038b0$0440aa10$@sprynet.com' \
    --to=sevaa@sprynet.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).