gmane.comp.gdb.devel

Re: add-inferior / clone-inferior

Luis Machado — 2013-05-20T15:52:16

Ok. It just seemed like the example you used was incorrectly assuming 
"target remote" would be able to do what "target extended-remote" does.


In the current scenario you would probably need a specialized debugging 
stub that would be able to multiplex between all of those boards. I've 
worked with a similar system before.

As for making GDB accept all those different connections at the same 
time, i don't think it is currently prepared for that.

Luis

Re: add-inferior / clone-inferior

David Taylor — 2013-05-20T15:46:07


Actually, no.  The issue is not extended-remote vs remote.  We have boxes
with multiple boards each running a kernel.  The box I tried running gdb
against on Thursday has 10 boards of interest.  Each running its own
instance of the kernel -- 2 instances each of 5 different versions of
the kernel.

For that machine if I want to talk to all 10 boards, then I need 10
different tcp connections -- each talking to a different gdb stub.

Re: add-inferior / clone-inferior

Luis Machado — 2013-05-20T15:06:15

This is expected since you can actually have two inferiors, but you are 
only allowed to connect to a single remote target at one time.

What would've worked is first connecting to a remote target in 
*extended* remote mode. Then you would be able to attach to more than a 
process at a time, or start more than a process at a time.

By using "target remote", you're really trying to debug an already 
active process running on a remote system.

I'd suggest reading about the extended remote mode. That looks like what 
you want, though multiprocess support is still a WIP.

add-inferior / clone-inferior

David Taylor — 2013-05-20T14:43:25

The commands add-inferior / clone-inferior and several related commands
were added as long ago as gdb 7.1.  But, unless I'm missing the obvious,
they aren't currently very useful.

GDB appears to support multiple "live" inferiors only when the arise as
the result of a fork or vfork.  Please tell me that I'm wrong and that
I'm missing the obvious.

    . I start up gdb with no arguments
    . file my-elf-file
    . clone-inferior
    . info inferiors

I now have two inferiors, numbers 1 and 2, same elf file; 1 is curent.

    . target remote <arguments>
    . inferior 2
    . target remote <different-arguments>

And I get:

    A program is being debugged already.  Kill it? (y or n)

I also tried attaching to two pre-existing processes, one each two
different inferiors.  That failed as well.

I've looked more at remote targets than attached / forked targets, as we
are more interested in remote targets.  Thursday last week I would have
loved to have had 10 inferiors, 5 elf files, 2 inferiors per elf file.

Loo

RE: GDB and libthread_db.so.1 issue

Avi Gozlan — 2013-05-19T08:04:08

Thanks doug.
Of course I have copied the 32bit /usr/lib/libpthread.so.0  to the target machine.

Yet following your emphasis on this specific file I double checked, and realized the /usr/lib/libpthread.so.o file is merely a text file... not the real library. The real 32bit one resides in /lib, not in /usr/lib.

Copying /lib/libpthread.so.0 and /lib/libthread_db.so.1 to the target resolved the problem.

Thanks a lot,

Avi

-----Original Message-----
From: Doug Evans [mailto:dje< at >google.com] 
Sent: Thursday, May 16, 2013 7:26 PM
To: Avi Gozlan
Cc: gdb< at >sourceware.org
Subject: Re: GDB and libthread_db.so.1 issue

On Thu, May 16, 2013 at 5:30 AM, Avi Gozlan <avi< at >checkpoint.com> wrote:

It's unfortunate that libthread_db errors aren't more descriptive.  I hate debugging these issues too.

Note that libpthread is linked into the app and libthread_db is loaded by gdb.
And they need to match.
You say you copied libpthread from another machine, but did you *also* copy the 32-bit version of libpthread from the other mac

Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?

Pedro Alves — 2013-05-17T10:15:05

Wow.

If you haven't yet, it'd make sense to try process vs core at the
exact same spot:

$ gdb myprogram
(gdb) run
...
(gdb) mymacro
(gdb) gcore mycore
(gdb) quit

$ gdb myprogram -c mycore
(gdb) mymacro


I'm really surprised.  If anything, I'd expect cores to be marginally faster.
I suggest git bisecting gdb looking.  Maybe you'll find the culprit
easily that way.


Ideally no, of course.  Let us know if that indeed helps.
Using DWARF < 4 should make it easier to git bisect the
culprit, as you can then start bisecting before the
patches that added support for DWARF4.

[GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?

Paul Smith — 2013-05-16T19:42:15

Hi all.  Is anyone aware of an issue with a big slowdown running macros
on core files?  I'm not sure if this is related to GCC 4.8 or GDB 7.6,
or what, but I'm seeing a 4x or more slowdown when running macros on
core files from previous releases.

Running against a live process is the same speed as before.

Details: we were building/debugging with the system compiler and
debugger (e.g., GCC 4.5.2 / GDB 7.2).  Speed of macros when dealing with
core files here was acceptable.  FYI, our code is C++ with a small to
moderate number of templates and compiled (in this case) with "-g", and
no optimization.

I wanted to use a new compiler with an encapsulated environment so we
could unify our build toolchain.  I created a separately-installed
version of GCC 4.8.0/binutils 2.23.2.

Then we discovered that trying to use older GDB instances with the
results of this build failed, because they couldn't read the DWARF4
object format generated by GCC 4.8.0.  I thought about dropping back to
an older DWARF format but instead

Re: GDB and libthread_db.so.1 issue

Doug Evans — 2013-05-16T16:26:22

It's unfortunate that libthread_db errors aren't more descriptive.  I
hate debugging these issues too.

Note that libpthread is linked into the app and libthread_db is loaded by gdb.
And they need to match.
You say you copied libpthread from another machine, but did you *also*
copy the 32-bit version of libpthread from the other machine?

GDB and libthread_db.so.1 issue

Avi Gozlan — 2013-05-16T12:30:05

Hello,

I have got a problem with debugging 32bit applications on a target x86_64 machine.

I use 64bit gdb 7.1 on a x86_64 machine (running 'file `which gdb`' returns ELF 64-bit LSB executable, AMD x86-64...)
I can debug 64bit applications successfully on this target machine. However, when trying to debug 32bit applications, I get the following error message:
Cannot find new threads: generic error

Both libpthread.so.0 and libthread_db.so.1 were copied from another machine, both are located in /lib64. (for the sake of trouble shooting I replaced also libc.so.6 and ld-linux-x86.so.2 with libraries copied from that same machine).

When debugging gdb itself, I saw that indeed these shared libraries are loaded by gdb (by running 'info shared'). Yet debugging fails with 32bit programs. The top of the gdb's backtrace for the failure is the following:

#0  thread_db_err_str (err=TD_ERR) at linux-thread-db.c:264
#1  0x0000000000497897 in find_new_threads_callback (th_p=0x7fffffffb760,
    data=0x7fffffffb840) at li

Re: Why gdb fail to make

Pedro Alves — 2013-05-16T09:42:27

...

That's correct.  i386-elf (a bare metal target) is not supported
by gdbserver.  gdbserver is meant to be run on a full feature OSs.

Re: Why gdb fail to make

hitlar — 2013-05-16T04:16:47

gdb configure, make & make install smoothly but i want configure gdbserver
with above package it gives following error message 

Shine< at >Shine-PC /usr/src/gdb-7.6.50-2/gdb/gdbserver-elf
$ ../gdbserver/configure --prefix=/usr/local/i386 --target=i386-elf
--disable-werror

checking compiler warning flags...  -Wall -Wdeclaration-after-statement
-Wpointe    r-arith -Wformat-nonliteral -Wno-char-subscripts
checking for dladdr... no
checking for errno... yes - in errno.h
checking whether strerror is declared... yes
checking whether strstr is declared... yes
checking whether perror is declared... yes
checking whether vasprintf is declared... yes
checking whether vsnprintf is declared... yes
checking for socklen_t... yes
checking for Elf32_auxv_t... no
checking for Elf64_auxv_t... no
Error: target not supported by gdbserver.





--
View this message in context: http://sourceware-org.1504.n7.nabble.com/Why-gdb-fail-to-make-tp231905p232080.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: Why gdb fail to make

hitlar — 2013-05-16T03:51:25

Good Morning,
Thanks for quick reply, Really this forum is best for quick response, again
a lot of thanks, all of you who reply & concerning person. 
 



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/Why-gdb-fail-to-make-tp231905p232075.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: [patch]: testsuite: run bash instead of sh when using brace expansion

Sergio Durigan Junior — 2013-05-15T23:24:23


Hey, thanks for the patch.

Next time, please make sure to send patches to
gdb-patches< at >sourceware.org.  Also I don't see you on gdb/MAINTAINERS, do
you have copyright assignment for GDB?  This patch is simple enough to
go in without a copyright assignment, but if you intend to send more
patches please let me know (in off) and I can get you started on the
process.


Two spaces between name and e-mail.

 ^^^^^^^^
You're using spaces instead of a TAB here.


I am not sure what others think, but instead of depending on bash (which
may not be available on all platforms), I'd rather rewrite those
commands to avoid brace expansions at all, thus making them compatible
with sh.  I am not a maintainer however, so you'd better wait for one
until you do that.

Thanks,

Re: [patch]: testsuite: run bash instead of sh when using brace expansion

Tom Tromey — 2013-05-15T14:55:05




I think it would be better to rewrite this code to compute the list of
filenames in Tcl, then just send a simple command.  It seems to me that
one can't rely on bash existing on the remote system.

Tom

Re: Why gdb fail to make

Eli Zaretskii — 2013-05-15T13:29:15

Thanks.

Re: Why gdb fail to make

Joel Brobecker — 2013-05-15T12:56:11

Done: http://www.sourceware.org/ml/gdb-patches/2013-05/msg00522.html
I also proposed that the patch be applied to the 7.6 branch.

Re: Why gdb fail to make

Joel Brobecker — 2013-05-15T11:29:33

I meant that the patching by hand until we get the fix in CVS
as the workaround. I will commit a fix momentarily, since I am
hacking on GDB at the moment...

Re: Why gdb fail to make

Eli Zaretskii — 2013-05-15T11:24:08

Right.


Sorry.


My understanding was that this is the solution, not a work-around.

Re: Why gdb fail to make

Joel Brobecker — 2013-05-15T11:10:56

I think that's from the following declaration in utils.h:

        enum errors;

This was reported recently, and we discovered that this type of
declaration was a GCC extension not supported by older versions
of GCC.

I thought we had this fixed, already, but it looks like not.
You can probably work-around the problem by adding

        #include "exceptions.h"

around the start of utils.h. Or configure with --disable-werror.

Re: [patch]: testsuite: run bash instead of sh when using brace expansion

Christian Groessler — 2013-05-15T11:05:48


Yes, that were my failures, too.

chris

Re: [patch]: testsuite: run bash instead of sh when using brace expansion

Luis Machado — 2013-05-15T11:02:58

Speaking of which, i see quite a few failures with this testcase, in the 
form of:

FAIL: gdb.dwarf2/dw2-dir-file-name.exp: 
compdir_missing__ldir_missing__file_basename: continue to breakpoint: 
compdir_missing__ldir_missing__file_basename
PASS: gdb.dwarf2/dw2-dir-file-name.exp: 
compdir_missing__ldir_missing__file_basename: set filename-display absolute
FAIL: gdb.dwarf2/dw2-dir-file-name.exp: 
compdir_missing__ldir_missing__file_basename: absolute
PASS: gdb.dwarf2/dw2-dir-file-name.exp: 
compdir_missing__ldir_missing__file_basename: set filename-display basename
FAIL: gdb.dwarf2/dw2-dir-file-name.exp: 
compdir_missing__ldir_missing__file_basename: basename

Not sure if it is related.