headers
Hans-Peter Nilsson | 1 Dec 2004 03:32
Picon
Favicon

sim: Handle and pass new required option -OPC for CGEN "desc".

Most CGEN-based simulators use the <target>-desc.h file from
opcodes (and by most, I mean two out of the total three), see
sim/m32r/Makefile.in and sim/frv/Makefile.in.  When the CGEN
option "-OPC" was introduced for generating that file, the CGEN
caller in opcodes was updated, but the one in sim wasn't.  So
i960 broke.  To repeat, build sim --target=i960-elf
--enable-cgen-maint or go to build/sim/i960 and make
"stamp-desc" (may need to "rm stamp-desc" or "touch
cgen/cpu/i960.cpu").  You'll see:

make cgen-desc CGEN=`if [ -f ../../guile/libguile/guile ]; then echo ../../guile/libguile/guile;
else echo guile ; fi` CGENFLAGS="-v" \
  cpu=i960 mach=all \
  archfile=/n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu
make[1]: Entering directory `/n/asic_slask/hp/simtest/srcobji960/sim/i960'
/bin/sh /n/asic/slask/hp/simtest/src/sim/i960/../common/cgen.sh desc
/n/asic/slask/hp/simtest/src/sim/i960 \
guile /n/asic/slask/hp/simtest/src/sim/i960/../../cgen "-v" \
	i960 "" i960 "" all "" \
	/n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu ignored
Skipping slib/sort, already loaded.
Skipping slib/random, already loaded.
No backtrace available.
cgen -s /n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cgen-opc.scm -s
/n/asic/slask/hp/simtest/src/sim/i960/../../cgen -v -f  -m all -a
/n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu -i all -H tmp-desc.h1 -C
tmp-desc.c1 -O tmp-opc.h1 
Loading cpu description /n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu
Including file simplify.inc ...
Analyzing instruction set ...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tobias Erbsland | 1 Dec 2004 12:52
Picon

Threading bug, already solved, or is there a workaround?


Hello

I'm currently try to debug a multithreaded application with gdb. It seems that
there are this threading problems described in the PROBLEMS document.
(It's a SuSE 9.2, but i installed gdb 6.3 in the hope, the bug is already 
solved.)

Is there already a solution for that problem? Or is there a workaround? 

kind regards
Tobias
Permalink | Reply | 5 comments |
headers
Frank Ch. Eigler | 1 Dec 2004 14:53
Picon
Favicon
Gravatar

Re: sim: Handle and pass new required option -OPC for CGEN "desc".

Hi, HP -

On Wed, Dec 01, 2004 at 03:32:59AM +0100, Hans-Peter Nilsson wrote:
> [...]
> I didn't
> commit the regenerated sim/i960 files, because they obviously
> haven't been regenerated since CGEN was last modified and
> they're too different from the version in CVS for me to decide
> whether the changes are benevolent, and there's no testsuite for
> it trigged by "make check-sim". :-(  [...]

Testsuites for "check-sim" are quite rare.  The way one normally
obtains confidence in regenerated simulators is by running the
gcc/gdb tests against the changed sim.

Thanks for your care & feeding of cgen.  (I'll get back to
you on the other cris stuff later today.)

- FChE
Permalink | Reply | 2 comments |
headers
Hans-Peter Nilsson | 1 Dec 2004 16:02
Picon
Favicon

Re: sim: Handle and pass new required option -OPC for CGEN "desc".

> Date: Wed, 1 Dec 2004 08:53:40 -0500
> From: "Frank Ch. Eigler" <fche <at> redhat.com>

> Testsuites for "check-sim" are quite rare.  The way one normally
> obtains confidence in regenerated simulators is by running the
> gcc/gdb tests against the changed sim.

A *very* weak confidence, and a roundabout way of doing it at
that!  I just want to raise a concern: I hope it isn't policy.

(I like test-suites, and ones exercising existing-code coverage,
functional coverage and fixed bugs is a minimum.  I could
rewrite the whole thing and not worry -- except of course to
check that the new code paths are covered!)  Besides, i960 is
obsoleted, removed from gcc, so no hope in current CVS for that.

> Thanks for your care & feeding of cgen.  (I'll get back to
> you on the other cris stuff later today.)

So they all say. :-)  I'd be most thankful to get that SID issue
resolved.  What are y'all using for CGEN debugging?  I tried
psd-1.2.1 but it doesn't seem guile-compatible.

brgds, H-P
Permalink | Reply | 0 comments |
headers
Andrew Cagney | 1 Dec 2004 16:25
Picon

Re: sim: Handle and pass new required option -OPC for CGEN "desc".

Hans-Peter Nilsson wrote:
> Most CGEN-based simulators use the <target>-desc.h file from
> opcodes (and by most, I mean two out of the total three), see
> sim/m32r/Makefile.in and sim/frv/Makefile.in.  When the CGEN
> option "-OPC" was introduced for generating that file, the CGEN
> caller in opcodes was updated, but the one in sim wasn't.  So
> i960 broke.  To repeat, build sim --target=i960-elf
> --enable-cgen-maint or go to build/sim/i960 and make
> "stamp-desc" (may need to "rm stamp-desc" or "touch
> cgen/cpu/i960.cpu").  You'll see:

I've now removed the i960; you were saying ;-)

Andrew

PS: Yes, sim specific testsuites are important.
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Dec 2004 18:16

Re: Threading bug, already solved, or is there a workaround?

On Wed, Dec 01, 2004 at 12:52:47PM +0100, Tobias Erbsland wrote:
> 
> Hello
> 
> I'm currently try to debug a multithreaded application with gdb. It seems that
> there are this threading problems described in the PROBLEMS document.
> (It's a SuSE 9.2, but i installed gdb 6.3 in the hope, the bug is already 
> solved.)
> 
> Is there already a solution for that problem? Or is there a workaround? 

Which problem, specifically, do you mean?  What symptoms do you see?

--

-- 
Daniel Jacobowitz
Permalink | Reply | 4 comments |
headers
Andrew Cagney | 1 Dec 2004 21:08
Picon

6.3.50.2004-11-31 instead of 6.3.50_20041131; Was: Changes to snapshot directory

Andrew Cagney wrote:
> I'm looking to change GDB's snapshots/ directory.  At present we've:
> 
>     ftp://sources.redhat/com/pub/gdb/snapshots/branch/
>     ftp://sources.redhat/com/pub/gdb/snapshots/current/
> 
> where the first directory contains tarballs from the most recent branch, 
> and the latter tarballs from the mainline.
> 
> The problem I see with this is that it is hard to track a snapshot 
> series vis:
> 
>     gdb-6.2.50 -> gdb-6.2.90 -> gdb-6.3 -> gdb-6.3.1
> 
> you need to ``just know'' that half is found in current/ and half is 
> found in branch/.
> 
> I can think of two alternatives:
> 
> - flatten things - snapshots/
> - have separate release series directories -  6.2, 6.3, ...
> 
> I've a vague preference for the former,
> thoughts?

In looking to implmement this I identified another simplification.  I 
think we can reduce things to:

6.2.90_2004-11-23 -> 6.2.90.20041123
6.3 -> 6.3
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eli Zaretskii | 2 Dec 2004 05:45
Picon

Re: 6.3.50.2004-11-31 instead of 6.3.50_20041131; Was: Changes to snapshot directory

> Date: Wed, 01 Dec 2004 15:08:11 -0500
> From: Andrew Cagney <cagney <at> gnu.org>
> 
> I've attached an attempt at revising the doco to reflect this.
> 
> comments?

Okay with me, except for this nit:

> ! 6.1.50.20020302, <at> * 6.1.90.20020304, or 6.1.0.20020308)
> !  <at> item  <at> var{major}. <at> var{minor}. <at> var{patchlevel}. <at> var{YYYY} <at> var{MM} <at> var{DD}-cvs
> ! a  <at> sc{cvs} check out drawn on  <at> var{YYYY}- <at> var{MM}- <at> var{DD} (e.g.,
> ! 6.1.50.20020302-cvs, <at> * 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs)

Why did you need to use  <at> * here?
Permalink | Reply | 1 comment |
headers
Tarun | 2 Dec 2004 10:18
Favicon

Query regarding assembly level debugging support

Hi All,

    I am generating object file in Elf/Dwarf format. The prime target is
to be able to debug the assembly code. That is we are able to step
through the assembly code showing line numbers and relative addresses.
The Dwarf (version 2.0) sections currently being included are 
- debug_line
- debug_abbrev
- debug_info.

     The linked out file is loaded without errors on GDB. When we run
the respective out file on GDB, the control of debugger moves to label
main in the assembly code ( Breakpoint 1, 0xa00200ec in main ()). When I
try to move to next instruction using "nexti", the control moves to next
address (Displaying: 0xa00200f0 in main ()). This continues till the
last address is reached. Only the address increments within the assembly
file are displayed and not the actual assembly source.

      When I try to single step using "step", the message prompted is
"Single stepping until exit from function main, which has no line number
information". Whereas if I disassemble one of the addresses give above,
entire assembly code which I am trying to debug is displayed.

      Does this mean that GDB does not support debugging of the assembly
code?

Regards,
Tarun
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tobias Erbsland | 2 Dec 2004 10:56
Picon

Re: Threading bug, already solved, or is there a workaround?


Hello

> > I'm currently try to debug a multithreaded application with gdb. It seems
> > that there are this threading problems described in the PROBLEMS
> > document. (It's a SuSE 9.2, but i installed gdb 6.3 in the hope, the bug
> > is already solved.)
> >
> > Is there already a solution for that problem? Or is there a workaround?
>
> Which problem, specifically, do you mean?  What symptoms do you see?

If i try to debug an multithread application with gdb, the threads aren't 
started. Without gdb all is working fine.

An minimal example program for Qt with qmake.

The regular output would be:

**snip**
drzoom <at> toe:~/Entwicklung/kdevelopthreadbug/bin> ./kdevelopthreadbug
start 5 thread
Start thread 0
Start thread 1
Start thread 2
Start thread 3
Start thread 4
Thread started
Thread started
Thread started
(Continue reading)

Permalink | Reply | 3 comments |

Gmane