This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/symtab] Handle weak functions as global


Daniel Jacobowitz writes:
 > This patch is a one liner, but requires a bit of explanation.  If you have a
 > version of glibc available with debugging symbols (in both ld.so and
 > libc.so), you can see the problem like this:
 > 
 >   - Compile a program which calls open ().
 >   - Run to main.
 >   - Set a breakpoint on open.
 >   - Continue - the breakpoint will not be hit.
 > 
 > [Separate debug files will show the bug if you point GDB at the right
 > directory; on Debian this is /usr/lib/debug, not sure where it is on RH
 > systems.]
 > 
 > What happens, in my setup at least, is that gdb searches first the
 > executable, then libc.so.6, then ld.so for "open".  It either finds a
 > trampoline in the executable or nothing at all (depending on your version of
 > binutils).  Then, it finds open in libc.so.6, which has type mst_file_text. 
 > Then it finds open in ld.so, which also has a symbol named open, which also
 > has type mst_file_text.  We did not find any mst_text symbol, so we settle
 > for returning the most recent mst_file_text symbol - which is the wrong one.
 > 
 > There's two strange things here.  The first is that we return the second
 > file symbol instead of the first; it doesn't much matter, since we'll be
 > wrong half the time anyway.  The second is that the symbol in libc.so is
 > marked as mst_file_text.  This turned out to be because BSF_WEAK handling
 > was added to elfread for non-code symbols, but not for code symbols; and
 > open is a weak entry point to libc.so.6 for historical reasons.  If we treat
 > it as global, paralleling the non-code symbol handling, then GDB will
 > resolve breakpoints on "open" reliably to libc.so.6 (assuming no other
 > shared library defines it).  This gives the debugger much better chances of
 > finding the right symbol - any situation more complicated would require
 > setting breakpoints at all functions named "open", which is a To-Do-Later
 > issue.
 > 

Interesting. This is just gdb not following in the symbol searches any
of the ELF scoping rules. Can you add a small testcase?

How about:

file1.c
---
void
bar (void)
{
  puts ("bar in u1");
}


file2.c
---
void bar (void);
void
foo (void)
{
  bar ();
}
 
void
bar (void)
{
  puts ("bar in u2");
}


foo.c
---
int
main()
{
  foo ();
  return 0;
}


If you compile the files with bar() as shared libraries, what version
of bar does gdb pick from main?



 > Is this patch OK?
 > 

Does it effect the testcase above?


 > -- 
 > Daniel Jacobowitz
 > 
 > 2004-11-01  Daniel Jacobowitz  <dan@debian.org>
 > 
 > 	* elfread.c (elf_symtab_read): Treat weak functions as global.
 > 
 > Index: elfread.c
 > ===================================================================
 > RCS file: /big/fsf/rsync/src-cvs/src/gdb/elfread.c,v
 > retrieving revision 1.47
 > diff -u -p -r1.47 elfread.c
 > --- elfread.c	23 Oct 2004 16:18:08 -0000	1.47
 > +++ elfread.c	1 Nov 2004 17:00:39 -0000
 > @@ -305,7 +305,7 @@ elf_symtab_read (struct objfile *objfile
 >  		}
 >  	      else if (sym->section->flags & SEC_CODE)
 >  		{
 > -		  if (sym->flags & BSF_GLOBAL)
 > +		  if (sym->flags & (BSF_GLOBAL | BSF_WEAK))
 >  		    {
 >  		      ms_type = mst_text;
 >  		    }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]