errors in GDB reading symbols

errors in GDB reading symbols

[kceiwH]

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,

Mao

Re: errors in GDB reading symbols

[kceiwH]

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.
>
> 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,
>
> Mao
>
>

Re: errors in GDB reading symbols

[Tom Tromey]

>>>>> ">" == kceiwH  <kceiwh@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

[Daniel Jacobowitz]

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

[Baurzhan Ismagulov]

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: errors in GDB reading symbols

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@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@lists.freepascal.org/msg13661.html

Tom

Re: errors in GDB reading symbols

[Daniel Jacobowitz]

On Tue, Aug 04, 2009 at 08:33:28AM -0600, Tom Tromey wrote:
> 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@lists.freepascal.org/msg13661.html

Sad to see so much stale information about GDB; at least it has one
defender on that list, though (thanks Jonas).

Forwarding with permission, from Marco van de Voort (CC'd; Marco, this
is an open list, so feel free to reply and it won't bounce):

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

> The (libgdb usage) was copied from RHIDE.

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

> Note that one of the main reasons is the lack of some systems not
> supporting multitasking. Not having a linkable version afaik will make
> using GDB in an IDE for such purposes difficult to impossible.

> Typically that means Dos/DJGPP, but there could some embedded uses
> here and there also.

If we don't gain anything from the removal of libgdb.a, DJGPP support
for the Free Pascal IDE is at least some reason to keep it.  Not a
great one, IMO, but better than none...

-- 
Daniel Jacobowitz
CodeSourcery

Re: errors in GDB reading symbols

[Daniel Jacobowitz]

Really CC'd this time, sorry.

On Tue, Aug 04, 2009 at 10:46:34AM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 04, 2009 at 08:33:28AM -0600, Tom Tromey wrote:
> > 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@lists.freepascal.org/msg13661.html
> 
> Sad to see so much stale information about GDB; at least it has one
> defender on that list, though (thanks Jonas).
> 
> Forwarding with permission, from Marco van de Voort (CC'd; Marco, this
> is an open list, so feel free to reply and it won't bounce):
> 
> > >Unfortunately, there's an IDE (Free Pascal?) that uses it.  I don't
> > >know of other uses.
> 
> > The (libgdb usage) was copied from RHIDE.
> 
> > >I'm still in favor of being rid of it; but we should warn them
> > >directly.
> 
> > Note that one of the main reasons is the lack of some systems not
> > supporting multitasking. Not having a linkable version afaik will make
> > using GDB in an IDE for such purposes difficult to impossible.
> 
> > Typically that means Dos/DJGPP, but there could some embedded uses
> > here and there also.
> 
> If we don't gain anything from the removal of libgdb.a, DJGPP support
> for the Free Pascal IDE is at least some reason to keep it.  Not a
> great one, IMO, but better than none...
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 

-- 
Daniel Jacobowitz
CodeSourcery

Re: errors in GDB reading symbols

[Jonas Maebe]

On 04 Aug 2009, at 16:33, Tom Tromey wrote:

> I think the Free Pascal folks already know about this problem:
>
> http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13661.html

Yes, I also forwarded Daniel's original message to the Free Pascal  
core list. I'm a member of the Free Pascal core development team, but  
not in the camp that favours writing a complete alternative debugger  
(although I really would appreciate it if someone could integrate the  
GDB patches I submit, because even after pinging twice http://sourceware.org/ml/gdb-patches/2009-06/msg00273.html 
  still appears to be in limbo).

I'm quite sure that in the end some people will write a new Object  
Pascal debugger from scratch anyway, at least for Windows (where GDB  
reportedly doesn't always work that well), but I'm not interested in  
maintaining a Mac OS X port of that and I will continue working on/ 
with GDB (if only because Apple changes internal low level details way  
too often for me to play catch up all the time, and because projects  
regularly mix different languages on that platform). The libgdb.a  
problem is also irrelevant to FPC's Mac OS X port, because the text  
mode IDE that uses it is not supported on that platform.


Jonas

Re: errors in GDB reading symbols

[Daniel Jacobowitz]

On Tue, Aug 04, 2009 at 04:52:04PM +0200, Jonas Maebe wrote:
> Yes, I also forwarded Daniel's original message to the Free Pascal
> core list. I'm a member of the Free Pascal core development team, but
> not in the camp that favours writing a complete alternative debugger
> (although I really would appreciate it if someone could integrate the
> GDB patches I submit, because even after pinging twice
> http://sourceware.org/ml/gdb-patches/2009-06/msg00273.html still
> appears to be in limbo).

Sorry - no matter what, I expect we'll always lose patches, but the
situation is much better than it's been in my memory.  Could you
resend that?

-- 
Daniel Jacobowitz
CodeSourcery

Re: errors in GDB reading symbols

[Tom Tromey]

>>>>> "Jonas" == Jonas Maebe <jonas.maebe@elis.ugent.be> writes:

Jonas> (although I really would appreciate it if someone could integrate the
Jonas> GDB patches I submit, because even after pinging twice
Jonas> http://sourceware.org/ml/gdb-patches/2009-06/msg00273.html still
Jonas> appears to be in limbo).

FWIW -- I try to review every patch that I think I have some chance of
reviewing well.  Unfortunately for you, your patches fall outside my
zone of comfort.

I do try to keep track of the unreviewed patches, but I'm not sure what
to do with that information.

All I can suggest is being more persistent and/or obnoxious in pinging :-).

Jonas> The libgdb.a problem is also irrelevant to FPC's Mac OS X port,
Jonas> because the text mode IDE that uses it is not supported on that
Jonas> platform.

Is libgdb.a still used on other platforms?  I won't push forward on
removing it if you still use it and you are reasonably active.  While I
would prefer that you switch to MI, I can understand that this is
non-trivial.

Tom

Re: errors in GDB reading symbols

[Jonas Maebe]

On 06 Aug 2009, at 19:07, Tom Tromey wrote:

>>>>>> "Jonas" == Jonas Maebe <jonas.maebe@elis.ugent.be> writes:
>
> FWIW -- I try to review every patch that I think I have some chance of
> reviewing well.  Unfortunately for you, your patches fall outside my
> zone of comfort.

I know the feeling (there's quite a few FPC issues lingering as well  
due to them falling outside the zone of comfort of the currently  
active developers).

> All I can suggest is being more persistent and/or obnoxious in  
> pinging :-).

Next week maybe, I don't have much time currently (paper deadline).

> Is libgdb.a still used on other platforms?  I won't push forward on
> removing it if you still use it and you are reasonably active.   
> While I
> would prefer that you switch to MI, I can understand that this is
> non-trivial.

It is definitely still very much used in the  Dos/go32v2 and Win32  
versino of the IDE. It is also used in our own builds of the Linux- 
version of the IDE, but less so in the versions packaged by  
distributions (mostly because of there being no separate working  
"libgdb.a" package).

Other than the implementation cost that you noted, the main opposition  
to using MI that I've heard are
a) as mentioned by Marco, it's probably impossible to use it on Dos  
(since there's no multitasking)
b) communication with gdb via MI is supposedly dreadfully slow on  
Windows (I don't have Windows, so I can't confirm or deny this)


Jonas

Re: errors in GDB reading symbols

[Daniel Jacobowitz]

On Thu, Aug 06, 2009 at 11:00:19PM +0200, Jonas Maebe wrote:
> b) communication with gdb via MI is supposedly dreadfully slow on
> Windows (I don't have Windows, so I can't confirm or deny this)

If it's dreadfully slow, they're doing it wrong.  There's plenty of
free and proprietary IDEs based on MI, and supporting Windows host.

-- 
Daniel Jacobowitz
CodeSourcery

Re: errors in GDB reading symbols

[Marco van de Voort]

> It is definitely still very much used in the Dos/go32v2 and Win32 versino of
> the IDE. It is also used in our own builds of the Linux- version of the IDE,

FreeBSD also.

> but less so in the versions packaged by distributions (mostly because of
> there being no separate working "libgdb.a" package).
> Other than the implementation cost that you noted, the main opposition to
> using MI that I've heard are

>a) as mentioned by Marco, it's probably impossible to use it on Dos (since
>there's no multitasking)

IIRC the win9x pipe situation is not very good either. Which limits you on
Windows too, if you still support win9x.

>b) communication with gdb via MI is supposedly dreadfully slow on Windows (I
>don't have Windows, so I can't confirm or deny this)

File I/O and starting binaries in particular on Windows is relatively slow,
which is why a fragmentation over multiple binaries is not desirable.
Moreover, it is simply not the culture on non-unix to do so.

Partially the earlier own debugger discussion is fueled by one of the
improvements of FPC's internal linker relative to LD, the experience that
makes the call for an own debugger so vocal. It knocks off tens of seconds
in the compile-start-with-debug cycle, and makes GDB the next bottleneck (this
is for Lazarus, not the textmode IDE)

This is also because most FPC users rate speed relative to something like
Delphi, and thus have a low tolerance for pain and slowliness. Delphi does
typically compile-start-with-debug in one second if the compile is
relatively incremental.....

Personally I think the own debugger part, even IF it ever comes to fruition
is still far, far away, and for a few selected platforms only. So we still
have to live with GDB quite a while.

Forcing the MI interface would effectively kill the textmode IDE, it is
effectively in maintenance for years. If there is something to be done on
the GDB side, I'd prefer investing time in libgdb. What are the problems
with it? Does something need updating, etc?

I don't see the point of the MI interface at all btw. What is the idea
behind it? And why does it need to be one size fits all to desperately?

Re: errors in GDB reading symbols

[Tom Tromey]

Marco> Partially the earlier own debugger discussion is fueled by one of
Marco> the improvements of FPC's internal linker relative to LD, the
Marco> experience that makes the call for an own debugger so vocal. It
Marco> knocks off tens of seconds in the compile-start-with-debug cycle,
Marco> and makes GDB the next bottleneck (this is for Lazarus, not the
Marco> textmode IDE)

FWIW, I'm definitely interested in speed problems in GDB.  If you find
them, and can characterize them nicely, please file bug reports.

Marco> Forcing the MI interface would effectively kill the textmode IDE, it is
Marco> effectively in maintenance for years. If there is something to be done on
Marco> the GDB side, I'd prefer investing time in libgdb. What are the problems
Marco> with it? Does something need updating, etc?

I think that historically libgdb is just an idea that never really got
beyond the "put a lot of .o files into libgdb.a" stage.

When I look at GDB, I think there are a few things that make it a less
than great library:

* No use of namespaces for functions and globals
* ABI changes every release
* Unfriendly "embedding" behavior: takes over signals, requires
  application discipline about calling wait(), etc.

I guess those are the big ones.  If they don't bother you, cool.

Marco> I don't see the point of the MI interface at all btw. What is the idea
Marco> behind it? And why does it need to be one size fits all to desperately?

I'm not really aware of the full history of MI, but one big advantage is
that lots of people use it and it is supported.

I suppose the basic idea is that a text-based protocol is more
future-proof than a binary ABI.  (Of course this is not intrinsically
true, but it is made true because I don't think that restricting GDB to
be ABI-compatible is reasonable.)

I have two reasons I would want to remove libgdb.  First, I think that
supporting gdb-as-a-library is too much work for not enough payoff.
(Though this reason is somewhat deflated if you don't mind the "anything
goes" approach.)  Second, libgdb.a slows down the build, which is
pointless for something we don't support.

Tom

Re: errors in GDB reading symbols

[Paul Pluzhnikov]

On Tue, Aug 11, 2009 at 1:59 PM, Tom Tromey<tromey@redhat.com> wrote:

> Second, libgdb.a slows down the build, which is
> pointless for something we don't support.

Can't the second reason be removed by making libgdb.a a separate (optional)
make target? Let people who need libgdb.a type "make libgdb.a" :-)


-- 
Paul Pluzhnikov

Re: errors in GDB reading symbols

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Tom> Second, libgdb.a slows down the build, which is
Tom> pointless for something we don't support.

Paul> Can't the second reason be removed by making libgdb.a a separate
Paul> (optional) make target? Let people who need libgdb.a type "make
Paul> libgdb.a" :-)

Yeah, that would work for me.  It seems ok considering that we don't
install libgdb.a, so anybody using it already must have a gdb tree
around.

But, given the push-back on removing this, I think I will just leave it
the way it is.

Tom