public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/15677] New: Cannot find bounds of current function after executing strrchr in glibc
@ 2013-06-25 6:20 vijunag at gmail dot com
2013-06-25 8:31 ` [Bug libc/15677] " neleai at seznam dot cz
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: vijunag at gmail dot com @ 2013-06-25 6:20 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15677
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).
gdb throws an error "cannot find bounds of current function error" the moment
the program steps into strrchr function and Im not able to debug my executable
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 "86b4900
<__x86.get_pc_thunk.bx>". I'm also unable to debug the executable after calls
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=5, argv=0xbffff784, env=0xbffff79c) at main.c:205
205 int main(int argc, char **argv, char **env) {
(gdb) n
220 FILE *rva = fopen("/proc/sys/kernel/randomize_va_space", "r+");
(gdb) n
221 if (rva) {
(gdb)
222 int val=0;
(gdb)
224 if (1==fscanf(rva, "%d", &val)) {
(gdb)………………………………….
225 if (val) {
(gdb)
237 fclose(rva);
(gdb)
242 } else if (val) {
(gdb)
273 main_config.argv0short = 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 = 0x1a6047c2
187417594 arange end
187417595 COMPILE_UNIT<header overall offset = 0x1a604872>:
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 bytes)
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
DW_LANG_Mips_Assembler
--
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: <glibc-bugs-return-19024-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
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: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
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" <sourceware-bugzilla@sourceware.org>
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: <bug-15615-131-WD3qwNuHbO@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15615-131@http.sourceware.org/bugzilla/>
References: <bug-15615-131@http.sourceware.org/bugzilla/>
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\x15615
--- Comment #5 from Ondrej Bilka <neleai at seznam dot cz> ---
On Fri, Jun 14, 2013 at 03:37:30PM +0000, bugdal at aerifal dot cx wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id\x15615
>
> --- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-06-13 13:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-25 6:20 [Bug libc/15677] New: Cannot find bounds of current function after executing strrchr in glibc vijunag at gmail dot com
2013-06-25 8:31 ` [Bug libc/15677] " neleai at seznam dot cz
2013-07-05 5:50 ` neleai at seznam dot cz
2013-08-20 9:48 ` neleai at seznam dot cz
2014-06-13 13:31 ` fweimer at redhat dot com
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).