Ton van Overbeek | 1 Aug 2004 05:23
Picon

Gdb-6.2: Some small problems on webpage.

On http://sources.redhat.com/gdb (and http://www.gnu.org/software/gdb)
there are 2 small problems in the News section in the bottom half of the
page:
- The July 30 item still mentions 6.1.1 (the link is pointing to the 6.2
  ANNOUNCEMENT). Just change the link text to 6.2.
- The link in the June 16 news item now points to the 6.2 ANNOUNCEMENT
  instead of the 6.1.1 ANNOUNCEMENT. I guess the easiest is to replace the
  link by plain text.

Ton van Overbeek

Andrew Cagney | 1 Aug 2004 21:25
Picon

Re: Gdb-6.2: Some small problems on webpage.

> On http://sources.redhat.com/gdb (and http://www.gnu.org/software/gdb)
> there are 2 small problems in the News section in the bottom half of the
> page:
> - The July 30 item still mentions 6.1.1 (the link is pointing to the 6.2
>   ANNOUNCEMENT). Just change the link text to 6.2.
> - The link in the June 16 news item now points to the 6.2 ANNOUNCEMENT
>   instead of the 6.1.1 ANNOUNCEMENT. I guess the easiest is to replace the
>   link by plain text.
> 
> Ton van Overbeek

Doh!  It should be fixed - I re-worded things a bit.  It turns out that 
all the old announcements in ../news/ had the same problem.

thanks,
Andrew

Kei Sakamoto | 2 Aug 2004 03:14

Re: multi-arched Linux target

Hello,

Does anyone have any suggestion about this?
Thank you.

Kei Sakamoto

From: "Kei Sakamoto" <sakamoto.kei <at> renesas.com>
To: <gdb <at> sourceware.org>
Sent: Wednesday, July 28, 2004 12:04 PM
Subject: multi-arched Linux target

> Hello,
> 
> I have a question about multi-arched Linux target.
> 
> I'm implementing the native debug support on Linux/M32R.
> http://www.linux-m32r.org
> 
> In order to support Linux target, config/tm-linux.h is necessary.
> But config/tm-linux.h causes build errors in full multi-arched
> environment because SKIP_TRAMPOLINE_CODE and IN_SOLIG_CALL_TRAMPOLINE
> don't have multi-arch definitions.
> 
> In file included from ../../src/gdb/defs.h:1135,
>                  from ../../src/gdb/gdb.c:21:
> ../../src/gdb/gdbarch.h:2071:2: #error "Non multi-arch definition of
> SKIP_TRAMPOLINE_CODE"
> ../../src/gdb/gdbarch.h:2093:2: #error "Non multi-arch definition of
> IN_SOLIB_CALL_TRAMPOLINE"
(Continue reading)

Booby Chen | 2 Aug 2004 04:52
Favicon

problems with gdb multi-thread debugging and memset

Hi all, 

when I use gdb to debug a multithread program like the following:

(gdb) inf thr
  4 Thread 2051 (LWP 14625)  0x420292e5 in sigsuspend () from /lib/i686/libc.so.6
* 3 Thread 1026 (LWP 14624)  sch_hd_core (arg=0x8ac60f8) at schrun.cpp:221
  2 Thread 2049 (LWP 14623)  0x420e0037 in poll () from /lib/i686/libc.so.6
  1 Thread 1024 (LWP 14619)  0x420b4b31 in nanosleep () from /lib/i686/libc.so.6

(gdb) n
221             memset(&req4sch,0,sizeof(req4sch));

and when I use the command "next", the thread 3 can not go on, but if I change the current 
thread to thread 4 and use the command "next", the thread 3 and 4 can go on. 

can anybody tell me the reason of this??Thanks.

Regards,
Booby Chen

Jim Blandy | 3 Aug 2004 09:13
Picon
Favicon

interface to partial support for DW_OP_piece in dwarf2expr.[ch]


Full support for the Dwarf DW_OP_piece operator in location
expressions would require major work on 'struct value' and its users.
But in many cases, compilers use DW_OP_piece in a restricted way, such
that all the multi-piece locations actually generated could be
expressed using the 'struct symbol' and 'struct value' we have today.

For example, on the PowerPC E500, the 32-bit upper and lower halves of
the 64-bit gprs have separate register numbers in Dwarf information,
but GDB has (pseudo-)registers that refer to the entire 64 bits.  So a
Dwarf 3 location expression that places one piece in an upper-half
register and another piece in the corresponding lower-half register
could be represented by a 'struct value' V where VALUE_LVAL (V) ==
lval_register and VALUE_REGNO (V) is the pseudo-register number.

Recognizing these cases requires calling out to architecture-specific
code.  When an patch implementing this was first posted, there was
general agreement that dwarf2expr.[ch] ought not call architecture
methods directly, as it did in the patch, but should instead return
the list of pieces; and that dwarf2expr.[ch]'s callers (specifically,
the code in dwarf2loc.c) should take care of whatever wrangling was
needed to turn that list of pieces into the right 'struct value',
architecture-specific or otherwise.  That thread starts here:

    http://sources.redhat.com/ml/gdb-patches/2003-05/msg00425.html

Here's a sketch of how we might extend the Dwarf expression evaluation
interface to return piece lists, meant to implement the suggestions in
that thread.  If this looks reasonable, then I'll do some more work
and post it for further review.
(Continue reading)

Daniel Jacobowitz | 3 Aug 2004 15:01

Re: problems with gdb multi-thread debugging and memset

On Mon, Aug 02, 2004 at 10:52:15AM +0800, Booby Chen wrote:
> Hi all, 
> 
> when I use gdb to debug a multithread program like the following:
> 
> (gdb) inf thr
>   4 Thread 2051 (LWP 14625)  0x420292e5 in sigsuspend () from /lib/i686/libc.so.6
> * 3 Thread 1026 (LWP 14624)  sch_hd_core (arg=0x8ac60f8) at schrun.cpp:221
>   2 Thread 2049 (LWP 14623)  0x420e0037 in poll () from /lib/i686/libc.so.6
>   1 Thread 1024 (LWP 14619)  0x420b4b31 in nanosleep () from /lib/i686/libc.so.6
> 
> (gdb) n
> 221             memset(&req4sch,0,sizeof(req4sch));
> 
> and when I use the command "next", the thread 3 can not go on, but if I change the current 
> thread to thread 4 and use the command "next", the thread 3 and 4 can go on. 
> 
> can anybody tell me the reason of this??Thanks.

What do you mean by "can not go on"?

--

-- 
Daniel Jacobowitz

Michael Chastain | 3 Aug 2004 16:09
Picon

new testsuite function for c++ ptype

Here is what I have been working on lately.  This isn't ready for code
review yet, but I want to share my design and get comments on that.

The problem: gdb.cp/*.exp contains 160 ptype tests.  Each of these tests
needs about five or six different output patterns to accommodate various
C++ compilers: four versions of g++, dwarf-2 and stabs+, plus the hp
ac++ compiler.

g++ changes with time.  The most recent change in g++ HEAD caused
several dozen new FAILs and I had to patch up a lot of test scripts.
Plus, some test scripts do not have any code at all to handle the
vagaries of virtual base pointers and synthetic operators,
so they just FAIL on those configurations.

I have tried to handle this variation with some regular expression
machinery but it's getting to be too much.  So I wrote a new procedure,
"cp_test_ptype_class", that actually reads each line of the ptype body
and processes it against a description of the class contents.
"cp_test_ptype_class" takes a lot of parameters, but it's not actually
that bad if you're cut-and-pasting from existing calls, which is how
everybody will write these things after I write the first 160.

The new "cp_test_ptype_class" will live in a new file,
lib/cp-support.exp.

Here is a sample.  Consider the C++ class:

  class A : virtual public V
  {
  public:
(Continue reading)

Andrew Cagney | 3 Aug 2004 16:57
Picon

Re: shared library support hookin the remote.c


>>> As for the information:
>>> 
>>>  >>>> >     a) The unrelocated starting address of a segment.
>>> 
>>> Is this the offset in the object file.
> 
> 
> Yeah, this should be the segment offset from the executable.
> 
> 
>>>  >>>> >     b) The length of the segment
>>>  >>>> >     c) The address (relocated) of the segment.
>>>  >>>> >     d) The address space associated with the segment (think harvard
>>> 
>>> Rather than this is the protection mask needed (r,w,x?)
> 
> 
> I don't think this is really needed.  Though having it wouldn't hurt
> if you want an additional check to make sure that you've found an
> appropriate section.

If GDB knows a segment is read-only, it also knows that it can cache it 
-> especially important for text sections.

>>>  >>>> >        architecture here).
>>>  >>>        f) object file path
>>> 
>>> How does this compare to what is found in /proc/*/*map*?
> 
(Continue reading)

Datoda | 3 Aug 2004 17:33
Picon
Favicon

td_thr_tlsbase in thread_db.h

In recent versions of thread_db.h, there is this
function:

/* Get address of the given module's TLS storage area
for the given thread.  */
extern td_err_e td_thr_tlsbase (const td_thrhandle_t
*__th,
				unsigned long int __modid,
				psaddr_t *__base);

Does anyone know where and how to get a module's modid
so that it can be used to call this function? Thanks.

	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Daniel Jacobowitz | 3 Aug 2004 20:51

Re: breaking at for-loop test line

On Fri, Jul 30, 2004 at 01:23:05AM -0700, Felix Lee wrote:
> Baurjan Ismagulov <ibr <at> ata.cs.hun.edu.tr>:
> > On Thu, Jul 29, 2004 at 11:58:40AM -0700, Felix Lee wrote:
> > > how about just that.  something like "asm 30" that will print all
> > > the machine instructions that correspond to line 30 of the
> > > source.
> > 
> > Do you mean something like the following?
> > 
> > (gdb) info line 223
> > Line 223 of "main.c" starts at address 0x804e384 <main+64>
> >    and ends at 0x804e3a0 <main+92>.
> > (gdb) disas 0x804e384 0x804e3a0
> 
> yeah, but it would be nice to take into account code optimization
> and exclude instructions in that range that aren't relevant to
> line 223.  but I don't know if there's enough debugging
> information to do that.

There is.  We may want to "fix" the output of info line.  What it is
right now is the first group of contiguous instructions in the line;
later groups are ignored.

--

-- 
Daniel Jacobowitz


Gmane