From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31679 invoked by alias); 25 Jun 2013 06:20:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 31624 invoked by uid 48); 25 Jun 2013 06:19:50 -0000 From: "vijunag at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/15677] New: Cannot find bounds of current function after executing strrchr in glibc Date: Tue, 25 Jun 2013 06:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.17 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vijunag at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00201.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=3D15677 Bug ID: 15677 Summary: Cannot find bounds of current function after executing strrchr in glibc Product: glibc Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: vijunag at gmail dot com CC: drepper.fsp at gmail dot com I am trying to debug my executable created from gcc-4.7.2(i686-pc-linux-gnu= ).=20 gdb throws an error "cannot find bounds of current function error" the mome= nt the program steps into strrchr function and Im not able to debug my executa= ble after that point. Im not sure if the dwarf records are corrupted or if the problem is with glibc. I did disassemble the code and noticed that epilogue/prologue sequence for the same was replaced with a call to "86b49= 00 <__x86.get_pc_thunk.bx>". I'm also unable to debug the executable after ca= lls to few functions which have hand-written assembly in glibc. (gdb) r Failed to read a valid object file image from memory. Breakpoint 1, main (argc=3D5, argv=3D0xbffff784, env=3D0xbffff79c) at main.= c:205 205 int main(int argc, char **argv, char **env) { (gdb) n 220 FILE *rva =3D fopen("/proc/sys/kernel/randomize_va_space", "r+"); (gdb) n 221 if (rva) { (gdb) 222 int val=3D0; (gdb) 224 if (1=3D=3Dfscanf(rva, "%d", &val)) { (gdb)=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80= =A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6. 225 if (val) { (gdb) 237 fclose(rva); (gdb) 242 } else if (val) { (gdb) 273 main_config.argv0short =3D strrchr(argv[0], '/'); (gdb) 0x08048430 in ?? () (gdb) Cannot find bounds of current function (gdb) Cannot find bounds of current function (gdb) However if I step-into strrchr function I can continue with debugging. I'm not sure if the problem is with gdb or If I'm missing some compilation flags while compiling glibc. Below is the dwarfdump output of strrchr and let me know if it is missing some important info. arange starts at 0x1478ac40, length of 0x00000045, cu_die_offset =3D 0x1a60= 47c2 187417594 arange end 187417595 COMPILE_UNIT
: 187417596 < 0><0x0000000b> DW_TAG_compile_unit 187417597 DW_AT_stmt_list 0x01e23163 187417598 DW_AT_ranges 0x004d5d88 187417599 ranges: 4 at .debug_ranges offset 5070216 (0x004d5d88) (32 by= tes) 187417600 [ 0] addr selection 0xffffffff 0x00000000 187417601 [ 1] range entry 0x1478ac90 0x1478ae99 187417602 [ 2] range entry 0x086b4900 0x086b4904 187417603 [ 3] range end 0x00000000 0x00000000 187417604 DW_AT_name ../sysdeps/i386/i686/multiarch/strrchr.S 187417605 DW_AT_comp_dir ~/libs/glibc/srcdir/string 187417606 DW_AT_producer GNU AS 2.23.1 187417607 DW_AT_language=20=20=20=20=20=20=20=20=20=20= =20=20=20 DW_LANG_Mips_Assembler --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-19024-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jun 25 06:58:33 2013 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 19101 invoked by alias); 25 Jun 2013 06:58:33 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 18279 invoked by uid 55); 25 Jun 2013 06:58:25 -0000 From: "neleai at seznam dot cz" To: glibc-bugs@sourceware.org Subject: [Bug libc/15615] Poor quality output from rand_r Date: Tue, 25 Jun 2013 06:58:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: neleai at seznam dot cz X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00203.txt.bz2 Content-length: 1453 http://sourceware.org/bugzilla/show_bug.cgi?id=15615 --- Comment #5 from Ondrej Bilka --- On Fri, Jun 14, 2013 at 03:37:30PM +0000, bugdal at aerifal dot cx wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=15615 > > --- Comment #4 from Rich Felker --- > On Fri, Jun 14, 2013 at 12:10:59PM +0000, neleai at seznam dot cz wrote: > > To test rand_r equivalent I wrote a simple generator (which is for > > mostly to test performance, I did not look for quality.) > > > > movd (%rdi),%xmm0 > > movdqa %xmm0,%xmm1 > > > > aesenc %xmm0,%xmm1 > > aesenc %xmm0,%xmm1 > > aesenc %xmm0,%xmm1 > > aesenc %xmm0,%xmm1 > > movd %xmm1, (%rdi) > > movd %xmm1, %eax > > shr $1, %eax > > There's no reason to believe this code will have acceptable period or > be unbiased. Instead of storing the AES result back to the state, you Well I wrote above > > To test rand_r equivalent I wrote a simple generator (which is for > > mostly to test performance, I did not look for quality.) Which was only to show that using cryptographic functions is not too slow. (You can alternatively use CRC32 instruction.) I am still not convinced that changing implementation is improvement as everybody which cares about quality uses random_r. I would accept an warning that rand_r is weak and one should use random_r. -- You are receiving this mail because: You are on the CC list for the bug.