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 To: Schlosser Lukas Cc: gdb@sourceware.cygnus.com Subject: Re: Symbolic Interpretation in GNU world. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: 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: > > > > class MyClass > > { > > private: > > int m_i ; // Integer Data with size as 4Bytes > > bool m_b ; // Boolean data with size as 1Byte > > }; > > > > > > 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: > > > > > > m_i = H\'000FFF > > m_b = H\'00 > > > > From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii 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 To: Jim Kingdon 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> 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" To: 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 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