Re: Updated MAINTAINERS file - work in progress

[Kevin Buettner <kevinb@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10960 bytes --]

On Feb 11,  1:40pm, Andrew Cagney wrote:

> Attached is a revised copy of the gdb/MAINTAINERS file.  In drafting
> this revision, I've endeavored to:

[...]

> 	o	not change the maintenance assignments
> 		I've been handed several proposals already
> 		but would like to keep that separate.

When (and where) will this discussion take place?

> For this discussion thread could I suggest (plead ;-) restricting the
> discussion to style rather than substance.

What are we supposed to be discussing then?  Are you simply asking us
if we like your new layout for the MAINTAINERS file?

If so, then I do (like it).  It makes the various roles much clearer
than before.

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@redhat.com
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: Schlosser Lukas <lukas.schlosser@siemens.at>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Symbolic Interpretation in GNU world.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <np1z5xnhhp.fsf@zwingli.cygnus.com>
References: <200002251926.OAA20810@mescaline.gnu.org>
X-SW-Source: 2000-q1/msg00446.html
Content-length: 4623

GDB could do what you want, but it seems like an awfully painful and
indirect way to do something pretty simple.

The painful way:

Assuming that the architecture of your VxWorks board is something GDB
supports, and has a simulator for (check the sim directory of the GDB
source tree), you could:

- build a full cross toolchain --- compiler, assembler, libraries,
  debugger --- for your VxWorks board's architecture
- write your dummy program
- run your dummy program on the simulator

The easy way:

It seems to me it'd take twenty minutes to hack up a Perl script that
uses 'unpack' to print out your log.



> 
> Hello,
> 
> I posted the attached mail on February 2nd, 2000 to 'bug-gdb@gnu.org' 
> - but I didn't get any response till now. I have to reach a decision, please
> help me!
> Due to the fact, that this was the only gdb newsgoup I found, I hope that
> you can name me a correct contact person to find the answer onto the
> following
> urgent questions:
> 
> (1)
> Does GNU somehow provide the "offline symbolic interpretation"
> functionality described below? (incl. big endian / little endian problem -
> meanwhile
> solved by disabling the appropriate #DEFINE!)
> 
> (2)
> If it is not provided and we realize the described approach, what
> exactly is the further proceeding? Do you centrally manage such
> enhancements?
> 
> 
> Mit freundlichen Grüßen / Best regards,
> Lukas Schlosser
> 
> --
> 
> Siemens AG Österreich
> Siemensstraße 88-92 / Bau 16
> A-1211 Wien
> 
> PSE TN SES15 (SIE)
> Tel: +43 51707 / 25262, Fax: +43 51707 / 55241
> Mail: Lukas.Schlosser@siemens.at < mailto:Lukas.Schlosser@siemens.at >
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Schlosser Lukas 
> > Gesendet am: Mittwoch, 02. Februar 2000 16:49
> > An: bug-gdb@gnu.org < mailto:bug-gdb@gnu.org >
> > Betreff: gdb extension?
> > Wichtigkeit: Hoch
> > 
> > Hello,
> > 
> > I have to find out (very urgently), whether I can extend the 
> > gdb for offline symbolic interpretation, but I have a big 
> > problem with "Big Endian" and "Little Endian" format:
> > 
> > I collect trace data (more or less C-structs) on a "big 
> > endian" machine (running on VxWorks) and write it to a buffer. 
> > This buffer is transferred to an NT PC ("little endian"), 
> > where it should be symbolically interpreted. 
> > (Please see attached example for details).
> > 
> > I thought of using the functionality of gdb in the following way:
> > .) I start the gdb under WinNT and load a simple program "dummy.exe".
> > .) Then I load the debug information, which was produced for 
> > the original machine ("big endian"). I tried already, and 
> > this is possible.
> > .) Then I set a breakpoint at a certain place in "dummy.exe", 
> > whose functionality is to read the whole trace buffer into 
> > the memory. 
> > .) I run the program and it automatically stops after having 
> > read the whole buffer into memory.
> > .) I can determine where this memory region starts, I know 
> > which datatype was traced at which position in my buffer -> 
> > by means of simple type casts giving a certain address 
> > (offset in buffer combined with start address of memory 
> > area), gdb automtically shows the detailed structure of the 
> > given data, just in the wrong format.
> > 
> > ==> The only problem is: How is it possible to let gdb 
> > interpret the raw data as "Big Endian" although it is running 
> > on an "Little Endian" Machine. The command "set endian big" 
> > does not work, it gives error message: "Byte order is not selectable".
> > 
> > Thanks for your help,
> > Lukas Schlosser.
> > 
> > Example:
> > <file://----------------------->
> > class MyClass
> > {
> > private:
> > int m_i ; // Integer Data with size as 4Bytes
> > bool m_b ; // Boolean data with size as 1Byte
> > };
> > <file://--------------------->
> > 
> > When this module is compiled by GNU C++, all the 
> > debugging information
> > (like, the class name, names of each data member, 
> > their types,size etc)
> > are stored in the \"stabs\".
> > 
> > Now, I get the following string from a dump tool:
> > H\'000FFF00
> > 
> > Now I want to map these values to the corresponding 
> > data members in MyClass. 
> > i.e.. A tool should load the \"stabs\", read the 
> > information for class
> > MyClass. It finds that there is a data member named 
> > \"m_i\" which is of
> > type int. It means, its size will be 4Bytes. So from 
> > the hex dump, it
> > extracts 4 Bytes and assign to the data member. So the 
> > output of this
> > tool should be:
> >
> > <file://-------->
> > m_i = H\'000FFF
> > m_b = H\'00
> > <file://-------->
> 
> 
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: toddpw@windriver.com
Cc: jtc@redback.com, hjl@valinux.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091328.IAA19934@indy.delorie.com>
References: <200003080845.AAA18410@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00642.html
Content-length: 1307

> As far as I'm concerned, passing the breakpoint pointer is the right way
> to go; we should get away from the assumption that a target side breakpoint
> is an address with some #define'd size, and push that stuff into a default
> implementation that can be invoked easily by people writing new target
> support.

I agree.

But if we do that, I'd also suggest to leave it to the target to
decide whether a particular watchpoint fired or not.

Right now, the API presented by GDB is based solely on the address:
bpstat_stop_status calls target_stopped_data_address and does all the
decision-making based solely on that address (and some info it keeps
internally about each watchpoint).

This API is extremely limited.  Typically, the target knows much more
about the watchpoint which triggered than the generic GDB code does,
so it can make smarter decisions.  But in order to do that, the target
needs more information about the watchpoint, and it needs to pass back
to GDB the result (whether the watchpoint triggered or not), not its
address.

Btw, if we let the target decide whether a given watchpoint triggered,
we can also resolve, once and for all, all the various conflicts
between target-specific limitations of hardware-assisted watchpoints,
which now need to be dealt with on the generic level.
From nsd@cygnus.com Sat Apr 01 00:00:00 2000
From: nsd@cygnus.com (Nick Duffek)
To: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <882mue$s0f$1@cronkite.cygnus.com>
References: <38A47E89.3F4674B3@mozilla.org>
X-SW-Source: 2000-q1/msg00236.html
Content-length: 341

In article < 38A47E89.3F4674B3@mozilla.org >,

>There are also various problems with threads.  A lot of times gdb won't exit
>after the last thread exits because it keeps trying to kill a process which
>doesn't exist any more.

I've got a similar report from elsewhere; I'll be checking into it shortly.

Nick Duffek
nsd@cygnus.com
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: store_floating() rewrite (was Re: bug in arm_push_arguments())
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BCDE18.EDDD0A6D@cygnus.com>
References: <38B6C4A1.7A1461C4@netwinder.org> <38BA642A.6F358273@cygnus.com> <1000228181141.ZM26089@ocotillo.lan> <200002281929.UAA03907@landau.wins.uva.nl> <bln453w9f.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00468.html
Content-length: 995

Jim Kingdon wrote:
> 
> > There is no explicit policy in GDB on which operations are allowed to
> > lose precision, and which operations are not supposed to lose
> > precision.  I think that if we're going to address the issues raised
> > here, we must determine such a policy, and document it.
> 
> Well, I think the intended policy (which probably isn't 100% true of
> the current implementation) is that precision should be kept when it
> is possible/feasible to do so, and that otherwise GDB can lose
> precision.

That is as close as a ``policy'' gets.  The only foot note being
everyone wishes GDB could to arithmetic using an emulation of the
targets FPU.

> That's bad in the sense that the user doesn't get a clear expectation,
> but what's the alternative?  Give an error if we would lose precision
> (is there even a general enough way to detect this?  I don't see the
> machinery for it now)?
> 
> P.S. Kevin Buettner's store_floating rewrite looked about right to me
> too.

Andrew
From alain.borlethote@free.fr Sat Apr 01 00:00:00 2000
From: "Alien" <alain.borlethote@free.fr>
To: <gdb@sourceware.cygnus.com>
Subject: Using gdbserver to debug shared library
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <004001bf71a5$d6d52a60$a355fea9@borlethote>
X-SW-Source: 2000-q1/msg00133.html
Content-length: 765

Hello, I work on an in-house embedded 
OS.  It uses ppc-eabi format.
We have already ported gdbserver. We would like to 
have
support for shared library. After looking in the 
source gdb, it seems that remote debbuging
of dynamic executable is not supported. I see at 
least the following problems:         
solib.c: #include <link.h> and read_memory (something
which implicitly cast the link_map structure) which 
disable the
cross 
use.         ppc-eabi.mt: the link with 
rs6000-tdep.o because
rs6000-tdep.c include xcoffsolib.h.
Has anyone else worked or is working on a cross 
gdb with
shared library support?
Thanks a lot in advance for your 
help.                                             
Alain