pending/1754: GDB Bug 329

[Michael Chapman <michael dot chapman at neuf dot fr>]

>Number:         1754
>Category:       pending
>Synopsis:       GDB Bug 329
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Fri Aug 20 10:48:01 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 Hi all,
 
 My apologies in advance if this is not the right way of rasing this 
 question.
 
 The GDB bug #329 seems to still be there (GDB 6.1) more than two years 
 after it has been found..
 
 My environment for this for a new remote target I am working on and gcc 
 cross compiler from cygwin.
 The analysis below is entirely correct. In my case the function without 
 debugging info (__udivsi3 in libgcc.a) is
 even in a different section in the executable file.
 
 Is anything happening? Does anyone already have a solution?
 
 Michael Chapman
 
 *Reporter's email:* 	don@sandvine.com
 *CC these people
 on PR status email:* 	
   	 
 *Number:* 	329
 *Category:* 	breakpoints
 *Synopsis:* 	stack tracing and breakpoints don't work properly if no 
 debugging symbols
 *Confidential:* 	no
 *Severity:* 	serious
 *Priority:* 	medium
 *Responsible:* 	unassigned
 *State:* 	open
 *Class:* 	sw-bug
 *Submitter-Id:* 	net
 *Arrival-Date:* 	Sat Feb 02 13:38:00 PST 2002
 *Closed-Date:* 	
 *Last-Modified:* 	Thu Jan 30 19:55:57 UTC 2003
 *Originator:* 	don@sandvine.com
 *Release:* 	5.1.1
 *Organization:* 	
 *Environment:* 	target=mips-wrs-vxworks
 cross from cygwin
 *Description:* 	vxWorks target image is comprised of many source files. 
 Some are compiled with -g, some are not.
 
 If I take a symbol which is not compiled with -g (e.g. printf), and from 
 the gdb shell put a breakpoint, I get an incorrect address for the 
 breakpoint.
 
 The error seems to come from linespec.c:1212, in the decode_line_1(). It 
 looks up the symbol with lookup_minimal_symbol(), which is correct, and 
 it gets
 a correct result. It then calls find_pc_sect_line(), which returns an 
 incorrect address (from some other module with -g on). This address is 
 then used for the breakpoint.
 
 
 
 *File Attachments:* 	
 *How-To-Repeat:* 	Build an image with a file without -g. Put a 
 breakpoint on a function in this non-g file, check that the address 
 matches expected.
 *Fix:* 	
 *Release-Note:* 	
 *Unformatted:* 	
 
 ------------------------------------------------------------------------
 
 or send email to interested parties 
 <mailto:gdb-gnats@sources.redhat.com,%20nobody@sources.redhat.com,%20don@sandvine.com,%20gdb-prs@sources.redhat.com?Subject=Re%3A%20breakpoints%2F329%3A%20stack%20tracing%20and%20breakpoints%20don%27t%20work%20properly%20if%20no%20debugging%20symbols&Bod y=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fcmd%3Dview%2520audit-trail%26database%3Dgdb%26pr%3D329> 
 
 
 
       Audit Trail:
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: