HDTenEightyP/NetNews huggingface dataset:
From: paul@aztec.ucsc.edu (Paul Tatarsky)
Subject: Gdb print struct members and SunOS sparc?
Reply-To: paul@terra.ucsc.edu
Organization: UC Santa Cruz CIS/CE
Distribution: gnu
Date: Thu, 23 Jul 1992 18:43:47 GMT

Sorry if this has been asked before, but has anyone seen
the following problem, and is it a configuration error on my part.

Environment:
sparc SunOS 4.1.2
gcc -v
Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/specs
gcc version 2.2.2
gdb 4.6 compiled with #define GCC_MANGLE_BUG in gdb/symtab.c

Sample Code:
foo.c:
typedef struct {
        int x,y,z;
    } FOO;

    printfoo( FOO foo )
    {
        printf("%d %d %d\n", foo.x, foo.y, foo.z );
    }

    main()
    {
        FOO bar;

        bar.x = 10;
        bar.y = 20;
        bar.z = 30;

        printfoo( bar );
    }

The problem:
unix> gcc -g -o foo foo.c 
unix> gdb foo
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.6, Copyright 1992 Free Software Foundation, Inc...
(gdb) break printfoo 
Breakpoint 1 at 0x22a4: file foo.c, line 7.
(gdb) run
Starting program: /auto/terra/b/staff/paul/foo 

Breakpoint 1, printfoo (foo={x = 4194433, y = 8292, z = 8296}) at foo.c:7
7               printf("%d %d %d\n", foo.x, foo.y, foo.z );
(gdb) print foo.x
$1 = 4194433
(gdb) print foo.y
$2 = 8292
(gdb) print foo.z
$3 = 8296
(gdb) 

Why do my other systems (non-sparc,non SunOS) return x=10 y=20 z=30???
Did I screw up the build for gcc, gdb, or both on SunOS?
Please reply by email. Thanks in advance!

 Paul Tatarsky         email: paul@terra.ucsc.edu
 UC Santa Cruz
 CIS/CE Board          


Newsgroups: gnu.gdb.bug
From: rha@hoqub.ATt.COM (Richard H Almquist)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 00:00:57 GMT

For gdb-4.6, the following include files do not exist in Linux.  

	<sys/reg.h>
	<machine/reg.h>

If this problem has not been fixed, I am willing to do it.  However you will
need to send me info on how to do it so that I don't do something that will
break the configuration for other machines.

				Richard Almquist
				rha@cbnewsi.att.com

Newsgroups: gnu.gdb.bug
From: leisner@trianguli.wrc.xerox.COM (Marty Leisner 311/? x?)
Subject: Problems with gcc/gdb
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 24 Jul 1992 16:44:35 GMT

I haven't analyzed this case but:
	gcc is producing working code
	gdb appears not to be working correctly

I'm using gdb 4.5 (compiled with gcc 2.1.x) and gcc 2.2.2 on a Sparcstation running SunOS 4.1.2.

Here's a test program:


typedef struct {
	int i;
	int j;
} FOO;

static bar(const FOO me)
{
	printf("i = %d, j = %d\n", me.i, me.j);
}

static FOO getfoo(void)
{
	FOO test;

	test.i = 5;
	test.j = 10;
	return test;
}

main()
{
	FOO re;

	re = getfoo();
	bar(re);
}



It works fine

leisner@trianguli$ ./test
i = 5, j = 10

In gdb,
leisner@trianguli$ gdb test
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) break bar
Breakpoint 1 at 0x22a8: file test.c, line 9.
(gdb) run
Starting program: /a/rockwell/dk2g/leisner/tmp/test 

Breakpoint 1, bar (me={i = 289407105, j = 8292}) at test.c:9
9               printf("i = %d, j = %d\n", me.i, me.j);


gdb is seeing me as garbarge, but the compiler is working...


--
marty
leisner.henr801c@xerox.com  
Member of the League for Programming Freedom

Newsgroups: gnu.gdb.bug
From: hideki@isl.rdc.toshiba.co.JP (Hideki Yoshida)
Subject: Remote debugging stub for IBM-PC wanted
Organization: Research & Development Center, TOSHIBA, Kawasaki, Japan.
Distribution: gnu
Date: Thu, 23 Jul 1992 04:02:17 GMT

We want to use the remote debugging facility of GDB to cross-develop
protected-mode software for IBM-PC compatibles on Suns. The stub file
for 386 included in the standard distribution of GDB does not have
machine-dependent functions in it, i.e.:

	1. I/O with serial port.
	2. Switching between real and protected mode.

Is there a freely distributable stub source for PC compatibles
including such PC-specific functions?
---
						YOSHIDA Hideki
						Information Systems Lab.
						Toshiba R&D Center
						hideki@isl.rdc.toshiba.co.jp

Newsgroups: gnu.gdb.bug
From: gnu@cygnus.com
Subject: Re: Couple of problems in building gdb
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 05:17:15 GMT

> While compiling, many warnings about shifts of n (12, 16 usually) > object
> size of 8.

These are due to bugs in the vendor's compiler.

It is perfectly valid to shift a small object by a larger number of bits.
E.g.

	unsigned char uc;
	long foo = uc << 16;

A char is automatically promoted to int or unsigned int whenever it is
used in arithmetic, according to the rules of C (either traditional or ANSI).
Therefore the warning is meaningless and useless.

Ignore the warnings -- or, preferably, file a bug report with the
vendor about it.

I have also seen warnings about shifts "changing in ANSI C" from other
compilers.  This is yet another compiler bug.  The code which they
are complaining about does *not* change meanings between traditional 
and ANSI C.  We could have inserted explicit casts to shut up the warnings.
We would prefer if GDB users complained to their vendors about the
compiler bugs instead.

	John Gilmore
	Cygnus Support

Newsgroups: gnu.gdb.bug
From: lepreau@mancos.cs.utah.edu (Jay Lepreau)
Subject: HP PA-RISC gdb 4.6 support is available
Organization: University of Utah CS Dept
Distribution: gnu
Date: Wed, 29 Jul 1992 11:31:39 GMT

You can pick it up from jaguar.cs.utah.edu, in dist/pa-gdb-4.6.tar.Z.
190K.  It's the files we changed or added from the stock 4.6.
You need to get the base dist for the rest.
dist/hpuxbin/gdb is an HP-UX binary.
(pa-gas.tar.Z is also there, as GAS and GCC are required to make this
useful.  Our PA support is in the "standard" gcc-2.x.)

This builds and works on PA-RISC systems running BSD and HP-UX 8.05.
Maybe more, but they've been tested a bit.

The files hppabsd-core.c and hppabsd-xdep.c from the stock 4.6 are
not needed.

Changes to symtab.c and cplus-dem.c have to do with demangling cfront
local variables and not with pa support.

Thanks to Paul Roberts, perobert@cs.utah.edu, who did all the bfd and
gdb4 work.  Several others at Utah did the 3.5 work, on which much is
based.

Please send bugs and fixes to pa-gdb-bugs@cs.utah.edu, not an individual.

Newsgroups: gnu.gdb.bug
From: rdb@oasis.icl.co.UK (Roger Binns)
Subject: configuring gdb
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 16:33:06 GMT

I am having considerable difficulty trying to run the configure script.
The reason is because the machine vendor has nothing to do with it.

The machine is a sparc, and the operating system is system v release 4.
Since svr4 is standard (well, close enough), I shouldn't have to provide
a vendor.  However, configure insists that I can't use

sparc-unknown-svr4

What can I use?

The machine vendor is actually ICL, and we have done the reference port of
sysvr4 to the sparc architecture.  There are no features or ommissions from
this machine, that make it different from stock svr4.

How do you suggest I get around this?

There are also 'bugs' in configure for the other parts of gdb, in that it
uses the bsd side of things (eg alloca.h which is in /usr/ucbinclude),
and not the system v side which is what it should.

Thanks for your time,

Roger
-- 
cs89rdb@brunel.ac.uk        Brunel University, Uxbridge, Middx, UK
rdb@oasis.icl.co.uk         International Computers Ltd., Bracknell, Berks, UK
"Is this stuff any good for ants? No, it kills them."

Newsgroups: gnu.gdb.bug
From: bothner@cygnus.com
Subject: Re: gdb-4.6 and Linux
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 06:16:32 GMT

> For gdb-4.6, the following include files do not exist in Linux.
>
>         <sys/reg.h>
>         <machine/reg.h>

They exist in the latest release(s) of gcc for Linux.
If you don't have that, you can just create empty files.

machine/reg.h is #included by bfd/trad-core.c.
However, it doesn't seem to need it - removing the #include
on both Linux and Ultrix seems to be harmless.   So I propose
just removing the #include <machine/reg.h> from bfd/trad-core.c.

Similarly, I suspect gdb/i387-tdep.c doesn't *really* need
<sys/reg.h> (and if it did, it would be a bug preventing
use of gdb for cross-debugging).  So that #include should also
be removed.

The final #include <sys/reg.h> in gdb/i386-xdep.c is more
problematical.  It is not needed under Linux because the
register definitions are in <sys/ptrace.h> instead of
the more traditional <sys/reg.h>.

It seems that <machine/reg.h> is traditional on BSD systems,
while <sys/reg.h> is traditional on SYSV systems  (which
do not have /usr/include/machine at all).  In many ways Linux
is closer to SYSV (it has no /usr/include/machine).

My proposal:

- Remove #include <machine/reg.h> from bfd/trad-core.c.
- Remove #include <sys/reg.h> from gdb/i387-tdep.c.
- Keep the #include <sys/reg.h> in gdb/x386-tdep.c.
- Move the register definitions from /usr/include/sys/ptrace.h
to /usr/include/sys/reg.h on Linux.
- After gdb-4.7 has been released, remove /usr/include/machine/reg.h
and /usr/include/machine from Linux.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.gdb.bug
From: jain@tramp.tmc.EDU (Kiran Jain)
Subject: How to use DBXTOOL OR XDBX with gdb
Organization: Mississippi State Univ.
Distribution: gnu
Date: Sat, 25 Jul 1992 06:23:34 GMT

Hi,
	Can anybody please suggest me how to make dbxtool compatible
	with gdb for c++ programs.

Thanks
Kiran.

--
   |\/\/\/|                 
   |      |               
   |  \  /|              
   | (o)(o)_             

Newsgroups: gnu.gdb.bug
From: l33@ws100.lrw.uni-bremen.de (Dirk Mattfeld)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 18:13:15 GMT

Dirk C. Mattfeld
Computing Center
University of Bremen
2800 Bremen 41
Germany

<dcm@lrw.uni-bremen.de>


Dear bug-gdb!

I have trouble installing gdb 4.6 on a MACH 2.6 System delivered by MtXinu. 

MtXinu delivers their systems with gcc 1.37 and gdb 3.5. I recently
installed gcc 2.2.2 (wich works pretty well) and now I wanted to have
gdb 4.6. This installation failed until now!

I configured gdb via 'configure i386-aout-mach', what was the only
combination making sense to me. An error occured configuring the
./gdb-4.6/gdb directory. The file ./gdb-4.6/gdb/configure.in contains
two large 'case' structures: in the first the '.mh' file is selected,
in the second the '.mt' file is selected.  The configuration failed
because the file ./gdb-4.6/gdb/config/i386mach.mt is not present. It
seems strange to me, that there is a file ./gdb-4.6/gdb/config/i386mach.mh.

I tried to help myself using i386mach.mh and the i386aout.mt file,
because the a.out linker format is used on my kind of systems. When
this constallation did not work, i tried to find out what the
i386aout.mt file does. I hoped to find a suitable file out of a couple
of files named i386*.mt. Apart from System V.4 all the files configure
exec.o i386-tdep.o and i386-pinsn.o in the ./gdb-4.6/gdb directory.
Furter on they configure tm-i386v.h or tm-i386v-g.h. All that seems to
be COFF stuff and not a.out as expected.

So why do you specify a i386mach target without supporting the a.out
format for i386. Perhaps i am wrong in configuring this type of
system. Or something went wrong in your file dependencies. Let me know
if you have an idea to solve my problems.

What I have now: I copied the i386aout.mt to i386mach.mt and the
configure succeeded. The compilation succeded too, but the new gdb
cannot read symbol tables properly. programs can be run via gdb, but
of course, no beakpoints etc. can be set. Please help me!


Regards

Dirk C. Mattfeld



Newsgroups: gnu.gdb.bug
From: grier@world.std.com (The Political Crony)
Subject: Help building gdb-4.6 on Mt Xinu Mach386
Organization: The World Public Access UNIX, Brookline, MA
Distribution: gnu
Date: Wed, 29 Jul 1992 16:34:33 GMT

I just installed gdb on my PC running Mt. Xinu Mach386 but
I can't find a configuration that fits. Has anybody done this?

I had similar problems with 4.5.

Thanks

Jim Grier
grier@world.std.com


Newsgroups: gnu.gdb.bug
From: witchel@xenon.stanford.edu (Emmett Jethro Witchel)
Subject: Build problem on hp9k840 -- No makefile in gdb
Summary: title says it all
Organization: CS Department, Stanford University, California, USA
Distribution: gnu
Date: Mon, 20 Jul 1992 20:31:15 GMT

	The title says it all.  My make of gdb halts for lack
of a Makefile in the gdb subdirectory. I think everything else
was fine.

Newsgroups: gnu.gdb.bug
From: warner@redding.etdesg.trw.com (Jeff Warner)
Subject: Looking for a X-windows interface to gdb?
Organization: TRW, Inc., Redondo Beach...
Distribution: gnu
Date: Fri, 24 Jul 1992 22:35:23 GMT

I don't know if this is the place to post, but here goes.

Does there exist a gdb X-windows interface.  Or should I use the xdbx
and modify for gdb commands.....


Thanks

jeff warner

Newsgroups: gnu.gdb.bug
From: pfieland@citron.sw.stratus.com (Peggy Fieland)
Subject: Re: Gdb on Sunos struct print problem?
Organization: Stratus Computer, Software Engineering
Distribution: gnu
Date: Mon, 27 Jul 1992 13:23:42 GMT

I suspect this is a gcc problem .  Disassemble the program and
you will see that foo is in fact addressed off a register, and not
where gdb says it is (an argument at offset 0).

Peggy




Newsgroups: gnu.gdb.bug
From: wurgler@zippysun.math.uakron.edu (Tom Wurgler)
Subject: GDB and F77 on Sun revisited
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 14:19:22 GMT

Hello again.

A thousand pardons.  I sent email on July 9th saying that I was having
trouble with GDB and F77.  Well, I was (and I still am) but my
assessment of the situation was WRONG.  Here is the opening salvo from
my last email:

>  I am trying to debug a F77 program on a Sun SPARCstation 1.  It pretty much
>  works.  There are just certain times when I get an error (in GDB) that I do
>  not know how to get around.  GDB seems to have no problems until I attempt
>  to reference a variable that is used in a subroutine call to an outside
>  package (such as SunPHIGS).  Here is a bit to show you what I mean:

And I went on to say that I could not print variables used in calls to my
outside package (here SunPHIGS).  Well that is true but not completely true.
I saw last week that GDB v4.6 was released and so I thought that I would grab
it and see if it would fix my problems.  When it too failed I investigated
even further.

Here is my new assessment of what is happening.  I had always noticed that,
for the most part, I couldn't print variables that were used in the calls to
the SunPHIGS package.  I was doing more testing and noticed that I got
"$1 = Cannot access memory at address xxxxxxxx." when I did "info locals".

In almost every subroutine in which I have these calls to the SunPHIGS
package, I use an INCLUDE file that come with SunPHIGS.  This INCLUDE file is
made up of INTEGER and PARAMETER statements (1107 lines worth).  I found that
if I didn't have the INCLUDE file, "info locals" worked.  When I used the
INCLUDE file, "info locals" choked.  So I jammed the contents of the INCLUDE
file into my code, commented out all of the PARAMETER statements and GDB
didn't choke.  So then I uncommented out groups of PARAMETER statements until
GDB failed.  It appears now that when I reach a certain limit of variables
defined by PARAMETER statements, that GDB chokes (ie, "info locals" chokes)
with the "Cannot access memory at address..." error.
         
Here is my environment:

Sun workstation, SPARCstation 1.

SunOS 4.1.1 (SunOS Release 4.1.1 (GENERIC) #1: Thu Oct 11 10:25:14 PDT 1990)

GDB versions 4.4 and 4.6.  I used "sun4os4" when I configured.

                           I used Sun's cc the first time.  Then I ran
                           "make CC=gcc" somewhere at the top and rebuilt.
                           I used gcc version 2.2.2.

F77 version 1.4.  I usually use the "-g -C" switches but I get the same
                  results using just "-g".

The "outside" package that I am using is SunPHIGS version 1.3.

Thanks for any light that you can shed upon this...

I apologize again for my earlier stupidity.  I hope that I didn't cause too
much trouble.

Please let me know if you need more information or if there is anything that I
can do to clarify what I have said here.

Bill Benedetto
wurgler@zippysun.math.uakron.edu

Newsgroups: gnu.utils.bug
From: roberte@beta.tp2.ruhr-uni-bochum.de (Robert Eckardt)
Subject: tar-1.10
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 25 Jul 1992 01:03:05 GMT

Hi * !

I want to report a bug in the verify-option of tar-1.10 that I use on
my 486/33 under ISC-Unix 2.2 (SysVr3.2):

To write, for example, the GNU-debugger on three 5 1/4"-disks as a
multiple-volume tar-`file' with verify, I used

> tar cvWMf /dev/rdsk/f0q15dt gdb-4.6.tar.Z

and I got:

> gdb-4.6.tar.Z
> Verify gdb-4.6.tar.Z
> gdb-4.6.tar.Z: data differs
> _

with the curser placed where shown.
Input produces no reaction (except for INT, which kills -- the verify-action
itself cannot be interrupted by INT)
The same is not only true for the raw device but also for the block device
(`tar cvWMf /dev/dsk/f0 gdb-4.6.tar.Z').
The problem does not occur when verifying a single disk.
The alternative I use for now is to list the contents of the disks again --
but this is, of course, no solution.
(Usually, one only wants to know whether the medium is defect or everything
 can be read back correctly.)
Experimenting with the -L option (e.g.`tar cvWMLf 10 /dev/rdsk/f0q15dt ...')
I found that tar writes only 10 blocks but verifies the complete disk !

I hope this helps you to locate the error.
If you need more information, I would appreciate if you send me some specific
questions/commands that I can try.

Robert

------------                                                    ------------
Robert Eckardt, Ruhr-Universitaet Bochum, Inst. f. Theor. Physik II, NB6/169
                D-W-4630 Bochum, Germany
Telefon: 0234 700 3709           E-Mail: RobertE@beta.TP2.Ruhr-Uni-Bochum.de
Privat:  Steinbrink 22, D-W-4300 Essen 11, Germany      Telefon: 0201 678602

Newsgroups: gnu.utils.bug
From: marke@ssd.fsi.COM (Mark Easter)
Subject: 3.62.16 glob/Makefile bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 14:03:52 GMT

The following lines require a slash character after $(srcdir):

VPATH = $(srcdir)
glob.o: $(srcdir)glob.h $(srcdir)fnmatch.h
fnmatch.o: $(srcdir)fnmatch.h

_______________________________________________________________
                                                                    /|  -
Mark W. Easter            FlightSafety International               / | /|
Staff Engineer            Simulation Systems Division         -----------
Computer Systems Group    Broken Arrow, Oklahoma 74012    Flight   \ |   
marke@fsi.com             918-251-0500   Fax 251-5597        Safety \|SSD
_________________ "1st in FAA Phase II Certifications" ____________________

Newsgroups: gnu.utils.bug
From: jkh@sparc3.UUCP (Jordan K Hubbard)
Subject: GNU tar 1.10 truly loses on long filename remapping misfeature.
Organization: Lotus Ireland
Distribution: gnu
Date: Wed, 29 Jul 1992 22:41:50 GMT

This has been a longstanding gripe but it took a couple of extra
cups of coffee before I felt steamed enough to comment on it. :-)

GNU tar (and, for that matter, most other tars I suppose) has a path
name length limitation that generally only shows up on very long
file/path names.  When this happens, GNU tar tries to be cute and
truncates the name to a "MaNgLeD" form that it later tries to rename()
after the tar has completed using a mapping file of sorts.  This fails
in the case where one is unpacking files on more than one filesystem,
such as in a complete system restore, since rename() cannot span
filesystems for obvious reasons.

I'd say the severity of this one is pretty high.

					Jordan
From: burkhold@gdss.commerce.ubc.ca (Thomas Kelly Burkholder)
Newsgroups: gnu.utils.bug
Subject: tar
Keywords: tar MaNgLeD
Date: 20 Jul 92 18:24:06 GMT
Distribution: gnu
Organization: University of British Columbia, Vancouver, B.C., Canada

Hi all -

First, I realize this is possibly the wrong forum for this question, but  
since I've had no response from my post to gnu.misc.discuss, I thought I'd  
try here:

Can anyone tell me why some files are replaced by "@@MaNgLeD.?" when I use  
gnu tar 1.10 to archive directories?

Here's what "tar -tf /dev/rst0" gave me:

..
menhir/Users/frauendo/Library/GDSSDoc...
menhir/Users/frauendo/Library/GDSSDoc...
@@MaNgLeD.0
@@MaNgLeD.1
@@MaNgLeD.2
@@MaNgLeD.3
menhir/Users/frauendo/Library/GDSSDoc...
menhir/Users/frauendo/Library/GDSSDoc...
..

Many thanks for any help anyone can offer - if I can't solve this, I may  
not be able to use gnu tar as my archiver.

-Thomas

Thomas Burkholder
burkhold@gdss.commerce.ubc.ca
Newsgroups: gnu.utils.bug
From: derek@boingo.med.jhu.edu (Derek Ney)
Subject: Bug in make-3.62 in file glob/glob.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 14:56:02 GMT

I have discovered a bug in GNU make version 3.62 in
the filename globbing routine glob_in_dir(). On line
451 of file glob/glob.c, a directory is opened with
opendir(), but it is never closed. This causes make
to eat up one file descriptor each time this routine
is called. One of the most common things that calls this
is the wildcard function. Make eventually runs out of 
file descriptors if the wildcard function is called too
many times. If fixed the bug by initializing the variable
stream to NULL and then closing the stream before the
return with closedir() if stream was non-null. Following
are diffs for my fixes
diff glob.c.orig glob.c
446a447,448
>       stream = NULL;
> 
511a514,516
>       if (stream != NULL)
>               closedir(stream);
> 
519a525,528
> 
>       if (stream != NULL)
>               closedir(stream);
> 

Newsgroups: gnu.utils.bug