[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#349688: retitle, provide patch for and details of bug#349688



retitle 349688 broken .eh_frame for one argument syscalls.
tags 349688 patch upstream sid sarge
quit

This bug is tracked in the glibc bugzilla here:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=2419

I am attaching a patch that fixes the issue.

Here is a dump of some info from glibc bugzilla:

The .eh_frame sections for the nptl single argument syscalls (close and fsync)
in glibc 2.3.6 are being created incorrectly.  Valgrind compains about this, as
discussed here:

http://sourceforge.net/mailarchive/forum.php?thread_id=7568951&forum_id=32038

valgrind emits the message:

DWARF2 CFI reader: unhandled CFI instruction 0:50

on startup of every program linking to the offending object.  This
creates a lot of noise.

readelf agrees that there is a problem with the sections:

$ readelf --debug-dump=frames /lib/tls/libc.so.6 > /dev/null
unsupported or unknown DW_CFA_50
unsupported or unknown DW_CFA_50
$

The patch I will attach shortly fixes the problem.  At least the error message
goes away and to me the CFI instructions now look correct.

FWIW, I noticed the problem on Debian stable (sarge) and current unstable (sid)
but it doesn't look like a Debian only issue.

The patch above is far enough removed from the final objects that the
correctness of the fix isn't obvious (to me anyway). To verify the fix I took
the output object and steped through the FDE instructions to create the CFI
table.	Then I checked that the CFI table corresponds to the subroutine in
question.

$ ar -x /usr/lib/nptl/libc.a close.o
$ readelf --debug-dump=frames close.o
The section .eh_frame contains:

00000000 00000010 00000000 CIE
  Version:		 1
  Augmentation: 	 ""
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa: r4 ofs 4
  DW_CFA_offset: r8 at cfa-4
  DW_CFA_nop
  DW_CFA_nop

00000014 00000020 00000018 FDE cie=00000000 pc=00000000..00000050
  DW_CFA_advance_loc: 12 to 0000000c
  DW_CFA_register: r3 in r2
  DW_CFA_advance_loc: 13 to 00000019
  DW_CFA_restore: r3
  DW_CFA_advance_loc: 21 to 0000002e
  DW_CFA_register: r3 in r2
  DW_CFA_advance_loc: 13 to 0000003b
  DW_CFA_restore: r3
  DW_CFA_advance_loc: 1 to 0000003c
  DW_CFA_def_cfa_offset: 8
  DW_CFA_advance_loc: 8 to 00000044
  DW_CFA_def_cfa_offset: 4
  DW_CFA_nop
  DW_CFA_nop
$
In order to decode the above I looked at sections 6.4 and Appendix
5 of http://www.arm.com/pdfs/TIS-DWARF2.pdf.  The CFI table described
above is show below.  I also filled in what I believe to be the CFI to
x86 register mapping and the callee saved registers.

				 fp  fp 	 ra
		 eax ecx edx ebx esp ebp esi edi eip
Loc	 CFA	 r0  r1  r2  r3  r4  r5  r6  r7  r8
0	 r4+4	 u   u	 u   s	 u   s	 s   s	 cfa-4
c			     r2
19			     s
2e			     r2
3b			     s
3c	 r4+8
44	 r4+4

key:
  = (blank) same as last (look up in same column to find value)
s = same_value rule
u = undefined rule
rN = register(N) rule

$ objdump -j .text -D close.o

close.o:     file format elf32-i386

Disassembly of section .text:

00000000 <__libc_close>:
   0:	65 83 3d 0c 00 00 00	cmpl   $0x0,%gs:0xc
   7:	00
   8:	75 1b			jne    25 <__close_nocancel+0x1b>

0000000a <__close_nocancel>:
   a:	89 da			mov    %ebx,%edx
   c:	8b 5c 24 04		mov    0x4(%esp),%ebx
  10:	b8 06 00 00 00		mov    $0x6,%eax
  15:	cd 80			int    $0x80
  17:	89 d3			mov    %edx,%ebx
  19:	3d 01 f0 ff ff		cmp    $0xfffff001,%eax
  1e:	0f 83 fc ff ff ff	jae    20 <__close_nocancel+0x16>
  24:	c3			ret
  25:	e8 fc ff ff ff		call   26 <__close_nocancel+0x1c>
  2a:	89 c1			mov    %eax,%ecx
  2c:	89 da			mov    %ebx,%edx
  2e:	8b 5c 24 04		mov    0x4(%esp),%ebx
  32:	b8 06 00 00 00		mov    $0x6,%eax
  37:	cd 80			int    $0x80
  39:	89 d3			mov    %edx,%ebx
  3b:	50			push   %eax
  3c:	89 c8			mov    %ecx,%eax
  3e:	e8 fc ff ff ff		call   3f <__close_nocancel+0x35>
  43:	58			pop    %eax
  44:	3d 01 f0 ff ff		cmp    $0xfffff001,%eax
  49:	0f 83 fc ff ff ff	jae    4b <__close_nocancel+0x41>
  4f:	c3			ret

Attachment: eh_frame.patch
Description: Binary data


Reply to: