GSoC Status Report #4

Hi,

Accomplishments;
* Event class is restructured. It now uses python lists and built-in methods.
* Work on InferiorThread class is almost finished.
* Work on Inferior class has started.
* gsoc-kayral-python branch is up! I'm gradually pushing my works to
the branch. Any reviews would be highly appreciated.

Plans;
o Put finishing touches on InferiorThread class.
o Put finishing touches on Inferior class.

Regards,
Oguz

errors in GDB reading symbols

Hi,

I try to write a program to convert a line number of the source code  
to the corresponding memory address. The program will link to libgdb,  
libbfd, libiberty, libopcodes, which are generated when you compile  
GDB. My problem is that the number of symbols (more than ten thousand)  
of a given executable file that my program reads is quite different  
from that (less than one hundred) GDB reads.

All I did is mainly calling the interfaces to read an executable file  
and its symbols. That is, I call exec_file_attach and  
symbol_file_add_main. They should read the file's symbols.
My last try is copying the codes from functions main (in gdb/gdb.c),  
gdb_main (in gdb/main.c), and captured_main (in gdb/main.c), without  
the statement captured_command_loop, and putting them in a single  
function in my program. I also changed the names of some local  
variables, so I don't need to pass them as parameters. And the paths  
such as BINDIR, DEBUGDIR, gdb_sysroot are set to the current directory  
".". Even though, the program still reads more than ten thousand  
symbols of a given executable file.

I compile my program with linking to libgdb, libbfd, libopcodes,  
libiberty. And I also compiled GDB and run it to test whether my  
program behaved correctly. They are based on the same codes. The only  
differences are the path names. So my program should behave like GDB.  
But my program reads much more symbols than the GDB does. Is there  
anybody knows why that happen. I appreciate if you can give a clue.

Regards,

Re: errors in GDB reading symbols

Forget it. I found the bug. I gave a different parameter to my  
program. Sorry to bother you.

Regards,

Mao

On Aug 1, 2009, at 5:38 PM, kceiwH wrote:

> Hi,
>
> I try to write a program to convert a line number of the source code  
> to the corresponding memory address. The program will link to  
> libgdb, libbfd, libiberty, libopcodes, which are generated when you  
> compile GDB. My problem is that the number of symbols (more than ten  
> thousand) of a given executable file that my program reads is quite  
> different from that (less than one hundred) GDB reads.
>
> All I did is mainly calling the interfaces to read an executable  
> file and its symbols. That is, I call exec_file_attach and  
> symbol_file_add_main. They should read the file's symbols.
> My last try is copying the codes from functions main (in gdb/gdb.c),  
> gdb_main (in gdb/main.c), and captured_main (in gdb/main.c), without  
> the statement captured_command_loop, and putting them in a single  
> function in my program. I also changed the names of some local  
> variables, so I don't need to pass them as parameters. And the paths  
> such as BINDIR, DEBUGDIR, gdb_sysroot are set to the current  
> directory ".". Even though, the program still reads more than ten  
> thousand symbols of a given executable file.
>

Re: errors in GDB reading symbols

>>>>> ">" == kceiwH  <kceiwh <at> gmail.com> writes:

>> I try to write a program to convert a line number of the source code
>> to the corresponding memory address. The program will link to libgdb,
>> libbfd, libiberty, libopcodes, which are generated when you compile
>> GDB.

I think we would prefer that you not use libgdb.  Nobody has worked on
turning gdb into a library in many years.  What you see in the tree is
not even the minimum necessary to get that to work.

I'd like to propose that we get rid of libgdb.a entirely.
I think all it does is slow down the build.

Tom

Re: errors in GDB reading symbols

On Mon, Aug 03, 2009 at 10:53:35AM -0600, Tom Tromey wrote:
> I think we would prefer that you not use libgdb.  Nobody has worked on
> turning gdb into a library in many years.  What you see in the tree is
> not even the minimum necessary to get that to work.
> 
> I'd like to propose that we get rid of libgdb.a entirely.
> I think all it does is slow down the build.

Unfortunately, there's an IDE (Free Pascal?) that uses it.  I don't
know of other uses.

I'm still in favor of being rid of it; but we should warn them directly.

--

-- 
Daniel Jacobowitz
CodeSourcery

Re: errors in GDB reading symbols

On Mon, Aug 03, 2009 at 01:01:38PM -0400, Daniel Jacobowitz wrote:
> Unfortunately, there's an IDE (Free Pascal?) that uses it.  I don't
> know of other uses.

Another one is RHIDE, but it isn't maintained and has problems with
recent gdb versions anyway.

With kind regards,
--

-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: Solibs and objfile BFD ownership

On Thu, Jul 30, 2009 at 9:15 AM, Tom Tromey<tromey <at> redhat.com> wrote:

> It seems to me that there are not many choices.  Either we must pick a
> single owner, pick an order, implement something like reference counting
> for BFDs, or have a separate function to clean up the BFDs.

Right.

Conveniently, 'struct bfd' has usrdata, which is unused in GDB.
Here is a stab at reference-counted sharing of BFDs between solib and
objfile.

--

-- 
Paul Pluzhnikov

2009-08-03  Paul Pluzhnikov  <ppluzhnikov <at> google.com>

	* objfiles.h (OBJF_KEEPBFD): Delete.
	(gdb_bfd_unref): New prototype.
	* objfiles.c (gdb_bfd_unref): New function.
	(free_objfile): Call gdb_bfd_unref.
	* solib.c (free_so): Likewise.
	(symbol_add_stub): Set refcount.

Index: objfiles.h
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.h,v
retrieving revision 1.60
diff -u -p -u -r1.60 objfiles.h

Problem with ddd and source file visibility

Hello,

I am having a problem using ddd: I cant seem to fix the source file
visibility in ddd.

here is the situation...

I have a project made up of the following components:
- library A in its own directory where source files are split in src and inc
directories
- library B in its own directory where source files are split in src and inc
directories
- the program itself in its own directory where source files are split in in
src and inc directories.

When I debug the executable file I can correctly see the main file (which is
part of the program) and it can debugged fine, until I try to step into a
function listed in library A.

If I open the "Open Source" Dialog, I can see the files being part of the
program, then I can see some header files of library A, but I cant see any
of the source files of library A.

I tried to add the directory both using the gdb 'directory' command from gdb
prompt, and  the 'GDB Settings' dialog box of DDD; nevertheless source files
for library A are nowhere to be seen :(

If I try to list a function defined in library A using 'list <FunctionName>'
here is the result:

Re: Problem with ddd and source file visibility

Nevermind...

I finally found the problem in Makefile for Library A
--

-- 
View this message in context: http://www.nabble.com/Problem-with-ddd-and-source-file-visibility-tp24803540p24803939.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: errors in GDB reading symbols

>>>>> "Daniel" == Daniel Jacobowitz <drow <at> false.org> writes:

Tom> I'd like to propose that we get rid of libgdb.a entirely.
Tom> I think all it does is slow down the build.

Daniel> Unfortunately, there's an IDE (Free Pascal?) that uses it.  I don't
Daniel> know of other uses.

Daniel> I'm still in favor of being rid of it; but we should warn them directly.

I looked into this yesterday.

Removing this doesn't shave much time off the build -- 5 seconds on my
machine.  Still, it would probably be good to do.  While doing this, I
did discover we have duplicate objects in libgdb.a, oops.

I think the Free Pascal folks already know about this problem:

http://www.mail-archive.com/fpc-devel <at> lists.freepascal.org/msg13661.html

Tom