* Updated MAINTAINERS file - work in progress
@ 2000-04-01 0:00 Andrew Cagney
2000-04-01 0:00 ` Kevin Buettner
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: GDB Discussion
Hello,
Attached is a revised copy of the gdb/MAINTAINERS file. In drafting
this revision, I've endeavored to:
o re-structure it slightly so that it is easier
to figure out the exact problem domain of
a given maintainer.
o prepare the file in readiness for when
all maintainers have write privs.
o not change the maintenance assignments
I've been handed several proposals already
but would like to keep that separate.
For this discussion thread could I suggest (plead ;-) restricting the
discussion to style rather than substance.
Assuming no one objects, I'll commit this file 24 hours after this
posting.
Andrew
Blanket Write Privs
Andrew Cagney ac131313@cygnus.com?
Stan Shebs shebs@cygnus.com?
Various Maintainers
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.
If there is no maintainer for a given domain then the problem falls to
the head maintainer.
Target/Architecture: Generic ISA - Instruction Set Architecture -
issues. API variants, CPU variants. *-tdep.c.
d10v target Andrew Cagney cagney@cygnus.com
d30v target Andrew Cagney cagney@cygnus.com
mips target Andrew Cagney cagney@cygnus.com
mn10300 target Andrew Cagney cagney@cygnus.com
powerpc target Elena Zannoni ezannoni@cygnus.com
arm target Jim Ingham jingham@cygnus.com
m32r target Michael Snyder msnyder@cygnus.com
Host/Native: Target specific native support - typically shared
libraries and quirks to procfs/ptrace/... A native maintainer works
with the arch and core maintainer when resolving more generic
problems.
hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com
djgpp native DJ Delorie dj@cygnus.com
win32 host & native Chris Faylor cgf@cygnus.com
x86 linux native Jim Blandy jimb@cygnus.com
hurd native Mark Kettenis kettenis@wins.va.nl
macos host & native Stan Shebs shebs@apple.com
hpux, hp pa native Jeff Law law@cygnus.com
Core: Generic components used by all of GDB
generic arch support Andrew Cagney cagney@cygnus.com
target vector Andrew Cagney cagney@cygnus.com
main (main.c, top.c) Elena Zannoni ezannoni@cygnus.com
readline Elena Zannoni ezannoni@cygnus.com
generic symtabs Jim Blandy jimb@cygnus.com
dwarf readers Jim Blandy jimb@cygnus.com
elf reader Jim Blandy jimb@cygnus.com
stabs reader Jim Blandy jimb@cygnus.com
tracing Michael Snyder msnyder@cygnus.com
threads Michael Snyder msnyder@cygnus.com
breakpoint.c Michael Snyder msnyder@cygnus.com
language support David Taylor taylor@cygnus.com
expression eval David Taylor taylor@cygnus.com
defs.h David Taylor taylor@cygnus.com
utils.c David Taylor taylor@cygnus.com
Scheme support Jim Blandy jimb@cygnus.com
svr4 shlibs (solib.c) Jim Blandy jimb@cygnus.com
coff reader Philippe De Muyter phdm@macqel.be
remote.c Andrew Cagney cagney@cygnus.com
sds protocol Stan Shebs shebs@apple.com
rdi/adp protocol Stan Shebs shebs@apple.com
gdbserver Stan Shebs shebs@apple.com
documentation Stan Shebs shebs@apple.com
testsuite Stan Shebs shebs@apple.com
UI: External (user) interfaces.
command interpreter Fernando Nasser fnasser@cygnus.com
gdbtk (c & tcl) Jim Ingham jingham@cygnus.com
libgui (w/foundry, sn) Jim Ingham jingham@cygnus.com
Write After Approval
* Indicates folks we need to get Kerberos/ssh accounts ready so they
can write in the source tree
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: UI_OUT component of libGDB available
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3898FD3C.9888BF77@cygnus.com>
X-SW-Source: 2000-q1/msg00099.html
Content-length: 1226
Hello,
I'm pleased to announce that Red Hat have integrated the UI_OUT
component (result builder object) which is part of the on going libGDB
project into the GDB sources. It will appear in the main CVS repository
shortly (1). The basic details of the UI_OUT component were discussed
in various postings on the gdb@sourceware list last year.
To allow for both some settling in and some room for debate (2), there
is going to be a period during which the new UI_OUT code co-exists with
the old printf style output. During this period, GDB can be built to
use the new UI_OUT code by configuring with (this will also be fixed):
./configure --enable-build-warnings=-DUI_OUT=1
With the UI_OUT code enabled, the only visible change is that GDB's
start up message includes:
GNU gdb 4.18.1 (UI_OUT)
[...]
(gdb)
as the first ui-out implementation is, funny enough, the existing text
interface.
This work was authored (in reverse alphabetic order) by Elena Zannoni,
Fernando Nasser and me (Andrew Cagney).
Andrew
(1) Don't forget that gdb/binutils are about to have their repositories
merged. If you download this week, you'll just need to re-download next
week.
(2) I'm sure that there is plenty of room for debate.
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: 5.0 known issues 2000-02-09
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000208092840.C15046@lucon.org>
References: <38A04DBB.F32C217F@cygnus.com>
X-SW-Source: 2000-q1/msg00171.html
Content-length: 799
On Wed, Feb 09, 2000 at 04:09:15AM +1100, Andrew Cagney wrote:
>
>
> GNU/Linux/PPC: It's status is unclear (and is being debated as I write
> this). I have a sinking feeling that it won't be ready until the 5.1
> time frame. Sigh.
>
Last time when I had access to Linux/PPC, my gdb was working ok on
Linux/PPC. Unfortunately, I no longer have any easy access to
Linux/PPC. There is very little I can do here. Going through my
change log, I see the following:
Wed Oct 27 13:34:15 1999 H.J. Lu <hjl@gnu.org>
* config/powerpc/linux.mh (NATDEPFILES): Add linux-thread.o and
lin-thread.o.
Tue Sep 14 09:32:51 1999 H.J. Lu <hjl@gnu.org>
* config/powerpc/nm-linux.h: New.
Since I cannot verify if they really fix the problem, I am very
reluctant to submit the patch.
H.J.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003081942.e28JgFa00230@delius.kettenis.local>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com>
X-SW-Source: 2000-q1/msg00613.html
Content-length: 1144
Date: Tue, 07 Mar 2000 15:27:48 -0800
From: Michael Snyder <msnyder@cygnus.com>
Hi Mark,
I appreciate your helping to find problems with it, and
I'd like to know what else in the code you regard as a
"loose end". One of my problems is that I'm not really
an experienced writer of multi-threaded apps -- I'm just
the person on the GDB team with the most experience with
GDB multi-thread debugging.
Well, the main "loose end" is that there seems to be some code to
take advantage of the event reporing facilities in libthread_db, but
GDB doesn't really use it right now.
Another thing is that the comment at the start of the file seems to
suggest that some code is shared with Solaris, but right now this
isn't the case.
Anyway, I'm not really experienced in writing multi-threaded apps
either. I've some experience in multi-threaded debugging on the Hurd
(where basically every program is multi-threaded), but the Hurd uses a
much saner approach than Linux. I'll do my best to help, but I
probably won't be able to take a serious look at GDB's way of handling
multithreaded apps in the next few weeks.
Mark
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: rearnsha@arm.com
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003211408.OAA03415@cam-mail2.cambridge.arm.com>
References: <38D75890.C5CC8261@cygnus.com>
X-SW-Source: 2000-q1/msg00755.html
Content-length: 1032
> "J.T. Conklin" wrote:
>
> > Todd> So I would have to argue that the singlestep logic must either
> > Todd> happen at a really low level (this guarantees it will patch last
> > Todd> and un-patch first) or must go through the real breakpoint logic
> > Todd> which can do duplicate detection.
> >
> > The SOFTWARE_SINGLE_STEP() macro is called at a low enough level that
> > it inserts and remove trap instructions without effecting GDB's high-
> > level breakpoints. So I think we're OK. As a result, I wouldn't be
> > suprised if steping into a breakpoint didn't behave the same as on a
> > machine with hardware single-step.
>
> Its got long-term problems.
>
> The code assumes that it is going to retain control, blocked on the
> target, while the actual step is performed.
> This doesn't work well within a pure event model where control is ment
> to return to the event-loop when ever the target is resumed.
It doesn't work properly with INSTRUCTION_NULLIFIED either -- at least it
didn't last time I tried it...
R.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Updated MAINTAINERS file - work in progress
2000-04-01 0:00 ` Kevin Buettner
@ 2000-04-01 0:00 ` Andrew Cagney
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Kevin Buettner; +Cc: GDB Discussion
Kevin Buettner wrote:
>
> 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?
Soon, you're free to start it even sooner :-)
> > 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?
Yep and technical problems et.al.
> If so, then I do (like it). It makes the various roles much clearer
> than before.
Since putting it forward several style things have occured to me:
Should I change the addresses to: <cagney at redhat dot com>.
Should (gasp) it include the name/e-mail of all people with a valid
assignment in place? Probably not. It probably should explain where
current list of people with an assignment is though.
You will have seen the proposed new file CONTRIBUTE. The opening
section is almost a straight lift of the GCC contribute page. I've
added a few GDB specific requests and comments. Would they be better in
the MAINTAINERS file? I suspect not as they are there to make the
contributers life easy.
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: P.Leggett@gre.ac.uk
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb functionality query
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BA6506.241FCCF4@cygnus.com>
References: <20000228114844.A3717@gre.ac.uk>
X-SW-Source: 2000-q1/msg00434.html
Content-length: 1664
Peter Leggett wrote:
>
> Hello,
>
> I hope that this list is the appropriate one to ask a general
> gdb question. If not please excuse this mail.
>
> The research group I work in uses the Sun debugger/dbx which has some
> these extremly useful features without which we would find debugging
> our codes much harder. We are now also running on linux boxes
> and are exploring the possibilites of gdb.
>
> I would very much appreciate it if anyone could tell me if gdb has
> the following specific functionality:-
>
> a) Ability to pop program call frame stack and then continue. I know one
> can browse up and down the frames in gdb but can one pop it and
> continue from a calling frame up the stack.
Yes:
(gdb) help return
Make selected stack frame return to its caller.
Control remains in the debugger, but when you continue
execution will resume in the frame above the one now selected.
If an argument is given, it is an expression for the value to return.
(gdb) help finish
Execute until selected stack frame returns.
Upon return, the value returned is printed and put in the value history.
> b) make an arbitary call to user code (with possibly arguments and
> expressions) from gdb and break point within that call etc..
> e.g.
>
> gdb-> break usersub
> gdb-> call usersub(a,fred+2,jim*2+1)
> ...
>
> where a, fred and kim are user variables.
Yes:
The commands are even identical.
(gdb) help call
Call a function in the program.
The argument is the function name and arguments, in the notation of the
current working language. The result is printed and saved in the value
history, if it is not void.
enjoy,
Andrew
From chrismehan@yahoo.com Sat Apr 01 00:00:00 2000
From: Hany Morcos <chrismehan@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: mmap
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000316162549.28863.qmail@web4003.mail.yahoo.com>
X-SW-Source: 2000-q1/msg00722.html
Content-length: 256
Howdy, gdb gurus,
I installed gdb on my linux box. I can't get it
to run with -mmapped option.
Any clues:-)
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000207161926.A11734@lucon.org>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com> <20000207093417.A10546@lucon.org> <200002072148.WAA08590@soliton.wins.uva.nl>
X-SW-Source: 2000-q1/msg00139.html
Content-length: 802
On Mon, Feb 07, 2000 at 10:48:37PM +0100, Mark Kettenis wrote:
>
> Yes we should try to act on bug-reports and look at the fixes we get
> from people. However, we should keep an eye on the long-term
> maintainability of GDB. Adding new hooks like Sam's patch does, is
> not improving maitainability and contrary to the current direction
> that GDB development is heading for: supporting multiple architectures
> in one GDB binary. The patch is very useful though for establishing
> what exactly is wrong, and how to fix this properly, which is what I
> intend to do. It is possible that this doesn't happen before GDB 5.0
> however.
But my past experences tell me that it usually means more tha 6 months,
a year or even never. That is why I suggested we set a deadline fo
cases like this.
H.J.
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: kettenis@wins.uva.nl (Mark Kettenis), gdb@sourceware.cygnus.com
Subject: Re: Testsuite regression
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14559.39965.642134.260490@kwikemart.cygnus.com>
References: <200003261706.e2QH6Yn08493@delius.kettenis.local> <200003261941.VAA32661@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00818.html
Content-length: 2664
I tested your fix on solaris and linux, it seems to work fine. I have
committed it. (Sorry, I know I shouldn't have done it w/o official
approval from Stan).
Elena
Peter.Schauer writes:
> I noticed this to, it is caused by:
>
> 2000-03-14 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
>
> * gdb.base/printcmds.c: Add typedeffed arrays.
>
> which now puts a nonzero word after ctable2 in gdb.base/printcmds.c via
> ArrayInt a1 = {2,4,6,8,10,12,14,16,18,20};
>
> Previous versions had
> int int1dim[12] = {0,1,2,3,4,5,6,7,8,9,10,11};
> after ctable2, putting a zero word there.
>
> So we now have a non zero byte after ctable2 (but only on little endian
> targets).
>
> p &ctable2[15*16]
> asks GDB to print an unsigned char pointer and GDB puts out the contents
> of the pointer as a string as well. As the string is no longer zero
> terminated, GDB appends ellipsis.
>
> It could be fixed by appending a zero byte to ctable2 (but I have tested
> this only lightly):
>
> *** gdb/testsuite/gdb.base/printcmds.c.orig Wed Mar 22 19:08:22 2000
> --- gdb/testsuite/gdb.base/printcmds.c Sun Mar 26 21:34:20 2000
> ***************
> *** 53,59 ****
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','X','X','X',
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','X','X',
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','X',
> ! 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a'
> };
>
> /* Single and multidimensional arrays to test access and printing of array
> --- 53,59 ----
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','X','X','X',
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','X','X',
> 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','X',
> ! 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a', 0
> };
>
> /* Single and multidimensional arrays to test access and printing of array
>
> > Hi all,
> >
> > Somewhere between March 9 and March 15, the following failure appears:
> >
> > FAIL: gdb.base/printcmds.exp: p &ctable2[15*16] with print elements set to 16
> >
> > This is the output from a run where the test still passed:
> >
> > p &ctable2[15*16]
> > $538 = (unsigned char *) 'a' <repeats 16 times>
> >
> > And this the current output:
> >
> > p &ctable2[15*16]
> > $538 = (unsigned char *) 'a' <repeats 16 times>...
> >
> > I'm a bit puzzled though what change is responsible for this
> > regression. Is there anybody else observing this failure?
> >
> > Mark
>
> --
> Peter Schauer pes@regent.e-technik.tu-muenchen.de
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: jimb@zwingli.cygnus.com (Jim Blandy)
Cc: toddpw@windriver.com (Todd Whitesel), gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: symfile.c:symfile_bfd_open()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003250821.AAA10529@alabama.wrs.com>
References: <npya7752wo.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00807.html
Content-length: 2618
> > Our local patch is to add a second argument to symfile_bfd_open,
> > "use_source_path", which ends up being set to 1 nearly all of the
> > time, since with our targets we are always cross developing. In
> > that case, we have openp() search source_path instead of getenv("PATH").
>
> How do you decide what to pass for the use_source_path argument? Is
> it a user-settable option?
It's not a user-settable option. (I never said these patches were clean;
in fact I was hoping to find a good way to clean them up, but it looks
like I've merely uncovered a more general issue that multi-arch is going
to raise as work continues on it.)
Since the main caller of symfile_bfd_open is symbol_file_add, we end up
adding an argument to him too, and that is what actually gets set by the
existing patches. The "decision" about what value to pass (if you can call
it that) is that in all the important cases we pass 1. All the lesser-used
(or never used!) cases pass 0.
It is my belief that all the 0 cases are incorrect yet harmless, but since
they almost never get used, no one was ever motivated to change them. I've
left them alone so far, because I had plenty else to do and they didn't
conflict with anything I was merging -- until 4.18 came along, that is.
> > Does the multi-arch stuff provide a clean test for native vs. cross?
> > That'd be a better decision-maker than the "use_source_path" argument.
>
> I don't think you can tell at all. What if I'm debugging an i386
> embedded system on Linux? Then, whether I'm native or remote is a
> matter of which target I select.
Kinda figured as much. This is something that multi-arch GDB does in
fact lose relative to a single-arch GDB, then.
I can think of at least 3 strategies for dealing with this, but the
bottom line is that GDB lets people pick files before requiring that
they pick a target. Perhaps this itself is what's wrong.
Anyway, the basic ambiguity right now is that you will probably want
a different PATH searched depending on native/cross, but GDB doesn't
know that answer yet.
Maybe the better solution is to have a three-state user settable option,
where the default is to search both PATH's, binary first and source second.
I expect in the future there will be more cases like this, where code that
always used to "just work" in the single GDB case finds itself lacking
information in the multi-arch arena because the target hasn't been chosen
yet, and no object files have been loaded. (This case is a little ironic,
in that it controls how we FIND those object files in the first place!)
--
Todd Whitesel
toddpw @ windriver.com
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: dan@cgsoftware.com
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7EDFB.7457@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00654.html
Content-length: 2082
Daniel Berlin wrote:
>
> >
> > Hi Mark,
> >
> > The lin-thread / thread_db module was completed under time
> > pressure and took much longer to get working than expected;
> > plus of course it is a brand new native thread "port"
> > (although I had access to Eric Paire's work as an example).
> > So no, it isn't formally regarded as a "work in progress",
> > except in the sense that GDB itself is a work in progress,
> > but it isn't exactly mature code either.
> >
> > I appreciate your helping to find problems with it, and
> > I'd like to know what else in the code you regard as a
> > "loose end". One of my problems is that I'm not really
> > an experienced writer of multi-threaded apps -- I'm just
> > the person on the GDB team with the most experience with
> > GDB multi-thread debugging.
>
> All i ever debug on BeOS is multi-threaded apps.
> Almost anything you do involves threads.
> Open a window, you've started at least 2 threads.
> File selection boxes fill in a seperate thread, etc.
> So i constantly have threads coming and going, and doing things.
> The hardest part of the whole port of gdb is telling gdb what
> happened, and making gdb do the right thing.
> On BeOS, we don't even have processes, just teams and threads.
> Everything on BeOS works, except typing run and have it start (you
> have to run and continue) :P.
> I looked at thread_db over the weekend, in hopes of being able to redo
> the port and get it into GDB (it's badly needing a rewrite anyway),
> but it still looks like it has too many problems.
What problems are you referring to?
Right now the only one I'm aware of is that it doesn't
detect thread exit.
> I'm more than willing to help with thread_db in any way i can to
> get it to work better.
> Like i said, all i ever work with is multi-threaded programs.
> My main C++ project is a development environment where almost
> everything is plugins, addons, and threads. At any given point in time
> there are about 16-20 threads going.
>
> >
> > Thanks,
> > Michael
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 Discussion <gdb@sourceware.cygnus.com>
Subject: gdb web re-arrage
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BC5206.21224C1A@cygnus.com>
X-SW-Source: 2000-q1/msg00452.html
Content-length: 240
Jim,
In prep for 5.0 what do you think of changing the gdb web pages so that
there is the url:
http://sourceware.cygnus.com/gdb/5/
for all the 5.0 release information. (I'd also move the 4.17 and 4.18
to their own directory).
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: 5.0 known issues 2000-02-16
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BF81BD.C7C35B59@cygnus.com>
References: <Pine.LNX.4.10.10002161044530.25408-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00517.html
Content-length: 699
Jimmy Guo wrote:
>
> >HP/UX: Unfortunately this was knocked about pretty badly by the move to
> >an external repository (sorry). Jimmy's looking at it along with Jason
> >and (possibly) Jeff (shared lib problem). I'm also going to try get
> >access to a HPUX box and give it a whirl.
>
> Provided that Jeff has applied the changes (include/hp-symtab.h) into
> the public repository, GDB should build for HP targets.
>
> Currently we're still relying on weekly snapshots to pick up updates. I
> know this would have to change for us to access CVS directly ... once
> there's a snapshot I will see if it is fixed ...
Just FYI, Hopefully the weekly snapshots are starting to flow again.
Andrew
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: gdb@sourceware.cygnus.com
Subject: Dwarf Error: Could not find abbrev number 1.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000311140313.A32545@visi.com>
X-SW-Source: 2000-q1/msg00676.html
Content-length: 2583
I recently updated my binutils (arm-elf target), and now when I
try to read symbols from some files (not all of them), I get a
dwarf error message. The odd thing is that some files work and
some don't (it seems to have something to do with which linker
command file is used). objdump and nm both seem happy with the
files, and I can "load" them fine, it's just the "symbol"
command that complains.
The only difference I can see between the files that work and
the ones that don't is the order of the section headers.
Any ideas what could have causes this?
------------------------------------------------------------
$ arm-elf-gdb
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
[...]
This GDB was configured as "--host=i586-pc-linux-gnu
--target=arm-elf".
JEENI (ADP, ARM7TDI) Rev 1.1
Rebuilt on Apr 13 1998 at 13:23:52
SN=9805J050 ENET=00:80:CF:00:03:31 IP=204.73.219.108
Connected to ARM RDI target.
(gdb) symbol lan
Reading symbols from lan...Dwarf Error: Could not find abbrev number 1.
------------------------------------------------------------
$ arm-elf-objdump --headers lan
lan: file format elf32-bigarm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00001170 00000000 00000000 00008000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000092 00001170 00001170 00009170 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00006158 00001210 00001210 00009210 2**4
ALLOC
3 .rodata 0000009d 00007368 00007368 0000f368 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .glue 00000000 00007408 00007408 0000f408 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .stab 000000d8 00000000 00000000 0000f408 2**2
CONTENTS, READONLY, DEBUGGING
6 .stabstr 00000009 000000d8 000000d8 0000f4e0 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_abbrev 0000026e 000000e1 000000e1 0000f4e9 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_info 000015f1 0000034f 0000034f 0000f757 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_line 0000080f 00001940 00001940 00010d48 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_pubnames 00000412 0000214f 0000214f 00011557 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_aranges 00000060 00002561 00002561 00011969 2**0
CONTENTS, READONLY, DEBUGGING
--
Grant Edwards
grante@visi.com
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Updated MAINTAINERS file - work in progress
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bhffg8fs0.fsf@rtl.cygnus.com>
References: <38A37686.BC866EB5@cygnus.com>
X-SW-Source: 2000-q1/msg00214.html
Content-length: 300
> Andrew Cagney ac131313@cygnus.com?
> Stan Shebs shebs@cygnus.com?
Well, I too am at least mildly puzzled by the "style vs. substance"
distinction but this looks good. In particular the two people above -
for blanket privs - is almost identical to the list that I came up
independently.
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Guenther Grau <Guenther.Grau@marconicomms.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000324101054.A2389@cygnus.com>
References: <200003241301.OAA04488@mail.macqel.be> <38DB7FF7.E3AFDE79@marconicomms.com>
X-SW-Source: 2000-q1/msg00797.html
Content-length: 521
On Fri, Mar 24, 2000 at 03:47:19PM +0100, Guenther Grau wrote:
>All major operating systems I know come with a reasonable modern
>iso-c compiler (or at least you can get one for it). And even if
>this weren't the case, you can always crosscompile gdb on a different
>platform (This feature needs more testing anyways ;-)
That was more-or-less the rationale for moving gdb towards a newer
standard. You obviously can't do this with gcc or binutils since they
may need to be compiled on a system which only has K&R.
cgf
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Ed.Swarthout@motorola.com, gdb@sourceware.cygnus.com
Subject: Re: State of native LinuxPPC patches
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000118211508.ZM1716@ocotillo.lan>
References: <http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00102.html> <200001182057.OAA26264@kuttanna.somerset.sps.mot.com> <swarthou@ibmoto.com>
X-SW-Source: 2000-q1/msg00044.html
Content-length: 1710
On Jan 18, 2:57pm, Edward Swarthout wrote:
> > Date: Thu, 21 Oct 1999 11:18:55 -0700
> > From: Kevin Buettner <kevinb@cygnus.com>
> >
> > I got my patches working with the head of the development tree several
> > weeks ago. (Actually, Gary Thomas deserves a lot of the credit.)
> > However there are a great many similarities between rs6000-tdep.c and
> > the ppclinux-tdep.c. I would really like to make the common parts
> > truly common as well as revamp it so that it uses the gdbarch
> > machinery, but this'll take more time than I have at the moment. So
> > it might be better for me to commit what I have so that linux/ppc is
> > supported in the Cygnus tree. Also, the longer I let my stuff sit,
> > the more likely it is that certain global changes will break what I
> > have working already. (Because these global changes won't have
> > happened to the linux/ppc stuff.)
> >
>
> Are these patches available in a sandbox somewhere?
I'd have to create some patches. (This should be doable.)
> (Since there isn't native support yet, are they harmless enough to be
> released in cvs before being tested?)
I've been told by several people that my linux/ppc patches should be
integrated with the other ppc related code before being put into CVS.
The fear is that once in CVS, it won't get integrated properly.
(There have been ample examples of this happening in the past.)
> I have a LinuxPPC debug project I need to work on and I wanted to
> switch to the latest gdb snapshot before I did much gdb work.
I understand. How soon do you need the patches?
I am scheduled to do some rs6000 work in a couple of weeks and I am
hoping to be able sneak some linux/ppc integration in...
Kevin
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, "Frank Ch. Eigler" <fche@cygnus.com>
Subject: [MAINT] src/sim directories
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B35D50.46EF286D@cygnus.com>
X-SW-Source: 2000-q1/msg00380.html
Content-length: 607
Hello,
If my understanding of history is correct, Cygnus has been slowly
accumulating/maintaining architectural simulators in the src/sim/*
directory and including them in with GDB. These simulators are both
used when testing GCC/GDB and when developing embedded applications.
Some simulators even have uses in a native environment - sim/ppc, for
instance, got to the point where it could run Linux/PPC binaries.
I'd like to first put Frank Eigler <fche at redhat dot com> forward as
the sim directory ``watch dog'' (I guess I'd be a fallback) and then
suggest a fairly lax maintenance policy.
Andrew
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Shared libraries on Linux
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002082201.RAA18487@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00175.html
Content-length: 5646
OK, I'm going to try to review the situation:
I'm using http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130 as
the key bug/limitation that *I* want to fix but of course one of the
things which is making this confusing is that people keep switching
topics between various bugs (current and past).
First there was:
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00105.html
http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00175.html
(I applied these together). This combo seems to fix the 5130 test
case for me. I've enclosed a version of this which is forward-ported
to GDB from CVS.
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00156.html
As Mark Kettenis points out, this one isn't hooked in the right place.
I tried it on the 5130 test case and it didn't help.
There is another test case at
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00107.html
which I haven't done anything with yet.
In summary: I'd like to second something Mark Kettenis said: "can we
please first establish what the exact bug is before we start trying to
hack around it!" All this flamage about cleanliness of code and hacks
and so on seems pretty much beside the point if we don't even have any
clarity about which bug we are trying to fix.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.1.1.27
diff -u -r1.1.1.27 infrun.c
--- infrun.c 2000/02/05 07:29:43 1.1.1.27
+++ infrun.c 2000/02/08 21:47:02
@@ -1497,6 +1497,9 @@
/* Switch terminal for any messages produced by
breakpoint_re_set. */
target_terminal_ours_for_output ();
+#ifdef CHECK_SOLIB_CONSISTENCY
+ CHECK_SOLIB_CONSISTENCY();
+#endif
SOLIB_ADD (NULL, 0, NULL);
target_terminal_inferior ();
}
@@ -2416,7 +2419,13 @@
/* Switch terminal for any messages produced by
breakpoint_re_set. */
target_terminal_ours_for_output ();
+#ifdef CHECK_SOLIB_CONSISTENCY
+ CHECK_SOLIB_CONSISTENCY();
+#endif
SOLIB_ADD (NULL, 0, NULL);
+#ifdef UNLOAD_UNUSED_SOLIB
+ UNLOAD_UNUSED_SOLIB();
+#endif
target_terminal_inferior ();
}
Index: lin-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/lin-thread.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 lin-thread.c
--- lin-thread.c 1999/12/22 21:45:07 1.1.1.1
+++ lin-thread.c 2000/02/08 21:47:04
@@ -102,13 +102,7 @@
#include "inferior.h"
#include "gdbcmd.h"
-#ifdef HAVE_WAIT_H
-#include <wait.h>
-#else
-#ifdef HAVE_SYS_WAIT_H
#include <sys/wait.h>
-#endif
-#endif
/* "wait.h" fills in the gaps left by <wait.h> */
#include "wait.h"
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 solib.c
--- solib.c 1999/11/17 02:30:28 1.1.1.10
+++ solib.c 2000/02/08 21:47:05
@@ -952,6 +952,90 @@
#endif /* SVR4_SHARED_LIBS */
/*
+
+GLOBAL FUNCTION
+
+ check_solib_consistency -- check solib list consistency
+
+SYNOPSIS
+
+ void check_solib_consistency (void)
+
+DESCRIPTION
+
+ This module is called whenever we hit a dynamic linker breakpoint
+ and allows us to check the consistency of our shared object list.
+ Without this, dynamic unlinking of objects could crash us.
+ */
+
+void
+check_solib_consistency (void)
+{
+#ifdef SVR4_SHARED_LIBS
+
+ if ( debug_base ) {
+ read_memory (debug_base, (char *) &debug_copy, sizeof (struct r_debug));
+ /* If the shared object state is consistent, we can reload our list */
+ if ( debug_copy.r_state == RT_CONSISTENT )
+ clear_solib();
+ }
+
+#endif /* SVR4_SHARED_LIBS */
+}
+
+/*
+
+GLOBAL FUNCTION
+
+ unload_unused_solib -- dump symbols from unloaded shared objects
+
+SYNOPSIS
+
+ void unload_unused_solib (void)
+
+DESCRIPTION
+
+ This module is called whenever we hit a dynamic linker breakpoint
+ and allows us to unload objects which are no longer valid in the
+ in the inferior.
+
+AUTHOR
+ Sam Lantinga <hercules@lokigames.com>
+ */
+
+void
+unload_unused_solib (void)
+{
+
+#ifdef SVR4_SHARED_LIBS
+
+ struct objfile *current;
+
+ for ( current=symfile_objfile; current; current=current->next ) {
+ struct so_list *so;
+ char *bfd_filename;
+ for ( so=so_list_head; so; so=so->next ) {
+ if (so->abfd) {
+ bfd_filename = bfd_get_filename (so->abfd);
+ if ( bfd_filename ) {
+ if ( strcmp(bfd_filename, current->name) == 0 ) {
+ break;
+ }
+ }
+ }
+ }
+ if ( (current != symfile_objfile) && (so == NULL) ) {
+/*printf("Freeing objfile: %s\n", current->name);*/
+ free_objfile(current);
+ break;
+ }
+ }
+
+#endif /* SVR4_SHARED_LIBS */
+
+}
+
+/*
LOCAL FUNCTION
Index: solib.h
===================================================================
RCS file: /cvs/src/src/gdb/solib.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 solib.h
--- solib.h 1999/08/31 01:06:02 1.1.1.3
+++ solib.h 2000/02/08 21:47:06
@@ -186,6 +186,15 @@
extern char *
solib_address PARAMS ((CORE_ADDR)); /* solib.c */
+/* Check shared library consistency */
+
+#define CHECK_SOLIB_CONSISTENCY() check_solib_consistency()
+extern void check_solib_consistency PARAMS ((void));
+
+/* Brute force check of library consistency */
+
+#define UNLOAD_UNUSED_SOLIB() unload_unused_solib()
+
/* If ADDR lies in a shared library, return its name. */
#define PC_SOLIB(addr) solib_address (addr)
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: cgf@cygnus.com (Chris Faylor)
To: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-09
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <87qhf9$10f$1@cronkite.cygnus.com>
References: <38A04DBB.F32C217F@cygnus.com>
X-SW-Source: 2000-q1/msg00180.html
Content-length: 587
In article < 38A04DBB.F32C217F@cygnus.com >, Andrew Cagney <ac131313@cygnus.com> wrote:
>Cygwin: Like HPUX, this has suffered badly from the binutils update. My
>understanding is that at present it doesn't build :-(.
It's more than that, actually. The current cygwin version of gdb has
problems finding symbols in a DLL, among other things.
The cygwin version could really use extensive testing. I'll volunteer
to make sure that that's done by enlisting my legion of cygwin gdb user.
I sure hope he's not on vacation.
cgf
--
cgf@redhat.com
http://www.redhat.com/
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Dan Hovang <dan.hovang@cpen.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Dumping memory to file
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38951323.C0DAFF1F@cygnus.com>
References: <387F9FAF.42F7B58E@cpen.com> <3884AECE.C627FD73@cpen.com>
X-SW-Source: 2000-q1/msg00074.html
Content-length: 1183
Dan Hovang wrote:
>
> Hello again,
>
> I solved it by adding a command, savemem, which does just that. It's
> most likely not a very good solution (it's my fist gdb hack), but I'm
> attaching the diff anyway, in case someone is interested.
>
> /Dan
>
> Dan Hovang wrote:
> >
> > I've got an embedded system running eCos which I'm debugging using
> > gdb over a serial line. I'm looking for ways to save blocks of
> > memory to disk in the good old brutal fashion, for example, after
> > hitting some breakpoing typing:
> > (gdb) save *0x0400 *0x07e8 "screendump"
A few quick BTWs
o While I personally have no opinion on
this command (commands are Fernando's domain)
I suspect a brief discussion about the
command, its syntax and how it fits into
the overall GDB cli may be in order.
Fernando, thoughts?
o I'd encourage you to have a quick read
of the GNU coding standard:
http://www.gnu.org/prep/standards_toc.html
http://sourceware.cygnus.com/gdb/submit.html
o in general patches go to
gdb-patches@sourceware.cygnus.com
Oh, congrats on remembering to include an update to the
documentation!!! That is something that is often forgotten.
enjoy,
Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002072148.WAA08590@soliton.wins.uva.nl>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com> <20000207093417.A10546@lucon.org>
X-SW-Source: 2000-q1/msg00136.html
Content-length: 1088
Date: Mon, 7 Feb 2000 09:34:17 -0800
From: "H . J . Lu" <hjl@lucon.org>
gdb 4.17.0.14 has one patch from Sam to deal with shared libraries.
People who want to debug shared libraries may not want to use gdb
in CVS. As you have mentioned above, it is not that unusual nowdays.
We have patches and they seem to work. We can make gdb 5.0 to work
with shared libraries. If we continue ignoring the working patches
without providing an alternative, we are sending the wrong signals
to those contributors.
Yes we should try to act on bug-reports and look at the fixes we get
from people. However, we should keep an eye on the long-term
maintainability of GDB. Adding new hooks like Sam's patch does, is
not improving maitainability and contrary to the current direction
that GDB development is heading for: supporting multiple architectures
in one GDB binary. The patch is very useful though for establishing
what exactly is wrong, and how to fix this properly, which is what I
intend to do. It is possible that this doesn't happen before GDB 5.0
however.
Mark
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: gdb@sourceware.cygnus.com
Subject: printing array element broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000202102302.A29253@visi.com>
X-SW-Source: 2000-q1/msg00095.html
Content-length: 1077
I've an array of 4 structures named txFrameDescrArray. When I
print the entire array, everything is fine:
(gdb) print/x txFrameDescrArray
$2 = {{FrameDataPtr = 0x100e10, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105610},
{FrameDataPtr = 0x101400, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105620},
{FrameDataPtr = 0x1019f0, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105630},
{FrameDataPtr = 0x101fe0, Reserved = 0x0, StatusAndFrameLength = 0x0, NextFD = 0x105600}}
However, asking gdb to print an individual element results in garbage:
(gdb) print/x txFrameDescrArray[0]
$3 = {FrameDataPtr = 0xfcfaa0ba, Reserved = 0xb8ff0003, StatusAndFrameLength = 0xbaeeffa2, NextFD = 0xb8ee70}
(gdb) print/x txFrameDescrArray[1]
$5 = {FrameDataPtr = 0xfcfaa0ba, Reserved = 0xb8ff0003, StatusAndFrameLength = 0xbaeeffa2, NextFD = 0xb8ee70}
What am I doing wrong?
GNU gdb 4.18
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
--
Grant Edwards
grante@visi.com
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Nick Clifton <nickc@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patch: Remove 'Dave' error message.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A8A875.88B6D8BD@apple.com>
References: <200002150059.QAA02943@elmo.cygnus.com>
X-SW-Source: 2000-q1/msg00276.html
Content-length: 654
Nick Clifton wrote:
>
> Hi Guys,
>
> Well I am sorry to have to do this, but we have a customer who got
> very confused by the Dave error message in GDB and wanted to know
> what a "Dave" was...
>
> So here is a patch to fix it. This patch was originally developed
> by Mark Alexander back in February of last year, but it appears to
> have been lost in patch limbo.
>
> Is it OK to apply this patch ?
Sigh, another nail in the coffin... we could salvage a tiny bit of
coolness by letting the original message (with corrected wording)
appear under the right circumstances - for instance, only for
executables named "hal9000"...
Stan
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Should GCC tell GDB about its optimizations?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-q1/msg00529.html
Content-length: 1860
I'm sure this subject has come up before, but I don't remember any
consensus...
In the process of finishing Mac OS X, Apple has hundreds of engineers
beating on GCC and GDB every day. The system has literally hundreds
of subcomponents; everything from the kernel to speech output to Hebrew
font support (sort of like a Linux system preloaded with everything
you can find on freshmeat :-) ). By default, everything is built with
optimization turned on. While an engineer can turn off optimization
for a specific bit of code, it's not practical to build an entire system
with optimization turned off. So in practice any single program consists
of a combination of optimized and unoptimized code.
Ideally of course, GCC would issue lots of amazingly detailed debug info,
and GDB would use it to reconstruct and report program state just as the
programmer expects to see it. But today, the result is just lame; hackers
trying to debug get lots of squirrelly behavior from GDB. The problem is
that they don't know whether the randomness is due to bugs in the program,
or to the effect of the optimizer. So the suggestion came up to have GCC
issue debug info stating what optimizations have been applied to a file,
and to have GDB report that information per-function, so that users could
lower their expectations appropriately.
Although my first reaction was to say "bleah", upon reflection I wondered
if I was too easily dismissing the concerns of real users of the tools.
This sort of thing routinely confuses users; even with years of GNU
experience, I still find myself being caught by surprise because I've
forgotten that part of the code was optimized. A simple warning from the
debugger would have saved me some time and trouble.
If there's consensus that this would be a worthwhile addition, I'll
work up a specific design and publish it.
Stan
From shebs@shebs.cnchost.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@shebs.cnchost.com>
To: Jason Molenda <jsm@cygnus.com>
Cc: gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: GDB snapshot 2000-01-31 out and IMPORTANT ANNOUNCEMENT
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <389710D7.6EF7B5A8@shebs.cnchost.com>
References: <20000131214333.A11195@cygnus.com>
X-SW-Source: 2000-q1/msg00084.html
Content-length: 514
Jason Molenda wrote:
> Here is the real crowd pleaser: At the end of the week I am going
> to migrate the active GDB repository from our internal repository
> to sourceware.cygnus.com. This means that all non-confidential[1]
> GDB development done here at Cygnus will be done in full public view.
> You'll be seeing the changes as they are added, warts and all. :-)
This is great, at long last! Is this going to be separate from the
binutils on sourceware still, or are you going to merge repositories?
Stan
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: GDB Developers <gdb@sourceware.cygnus.com>
Subject: Re: Readline and -DMINIMAL
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000328105123.G27306@cygnus.com>
References: <200003281230.EAA15638@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00824.html
Content-length: 1058
On Tue, Mar 28, 2000 at 04:30:19AM -0800, Todd Whitesel wrote:
>I have just discovered to my horror that the upgrade to Readline 2.2 in
>GDB 4.18 has completely eradicated support for the MINIMAL #define, and
>provides no alternative -- it simply assumes BSD style ttys and falls
>over dead if those aren't supported.
>
>Does anyone know the story on this one? Is there a stub library that
>is used for Cygwin and DJGPP ? I noticed a specific hack for cygwin
>that simply assumes libtermcap.a, I suppose this is a B20 invention.
>
>I really do not want to hack all the #ifdef MINIMAL stuff back in, but
>since I build direct on windows I need to shut up all the code that tries
>to use sgtty or termios.
You should probably send this email to the readline maintainer. The
readline in gdb 4.18 has, I believe, the most recent version of readline
available when it was released. The readline directory in CVS is version
4.0 with changes from Eli Zaretskii (I hope he also notified the readline
maintainer about these) to get things working on DJGPP.
cgf
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: hjl@lucon.org, shebs@apple.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m4saivyew.fsf@jtc.redbacknetworks.com>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00586.html
Content-length: 1011
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> Either way is fine with me. All I want is regex in glibc 2 :-). Any
Mark> objections?
Mark> Is this really important? From an engineering standpoint introducing
Mark> a dependency on glibc may not be the right thing. I've seen a quite a
Mark> few problems related to regex.h that were caused by getting out of
Mark> sync with glibc. I'd prefer not to add this to GDB 5.0.
I think Mark makes a good point. In fact, I vaguely remember
conflicts with regex.c/regex.h that caused those files to be renamed
to gnu-regex.c/gnu-regex.h back in the mid 90's.
If it is at all important to use the host regular expression routines,
perhaps we should investigate changing the calls used by GDB from the
old BSD re_comp()/re_exec() API to the POSIX.2 regcomp()/regexec() API
and using the host headers/library if the host provides it. I'd
prefer going that route than special casing glibc.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B319C4.F4AF10E7@cygnus.com>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local>
X-SW-Source: 2000-q1/msg00376.html
Content-length: 3018
Franz Sirl wrote:
> >I'm seeing 33 failures in the test suite at the present time. There
> >are some things which *should* work, like backtracing through signal
> >handlers, but which don't for some reason. In the coming days, I
> >will attempt to reduce the number of failures. In particular, I
> >will make sure we can backtrace through signal handlers. (I put
> >a lot of time into this in the initial port, and want to make sure
> >that it'll work again in the present port.)
> >
> >I invite those of you who have Linux/PPC machines to try out these
> >changes and let me know how they work. Also, please let me know about
> >any problems that you find.
Just a BTW, 33 failures is pretty good.
> I've just uploaded an RPM with the current CVS source to
> ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it.
>
> This is the only warning that shines up without any -W option:
>
> gcc -c -O2 -fsigned-char -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../intl -I./../int
> l -I./tui gdbarch.c
> gdbarch.c: In function `_initialize_gdbarch':
> gdbarch.c:3274: warning: assignment from incompatible pointer type
FYI, That isn't a GNU/Linux/PPC specific problem - an external interface
was tweeked.
> I configured with --prefix=/usr --disable-gdbtk --disable-sim. disable-gdbtk
> seems to be needed to let configure succeed with an already installed
> tcltk-8.0.5. I wonder if the toplevel configure.in should be modified to
> disable the simulator by default on powerpc-*-linux*?
>
> Then I needed a small patch for gdb/Makefile.in to let "make install" succeed:
>
> --- gdb-5.0/gdb/Makefile.in~ Tue Feb 22 02:35:42 2000
> +++ gdb-5.0/gdb/Makefile.in Tue Feb 22 15:23:21 2000
> @@ -649,18 +649,6 @@ install-only:
> fi ; \
> $(INSTALL_PROGRAM) gdb$(EXEEXT) $(bindir)/$$transformed_name$(EXEEXT) ; \
> $(INSTALL_DATA) $(srcdir)/gdb.1 $(man1dir)/$$transformed_name.1
> - $(SHELL) $(srcdir)/../mkinstalldirs $(datadir)/gdbtcl ; \
> - $(SHELL) $(srcdir)/../mkinstalldirs \
> - $(datadir)/gdbtcl/images \
> - $(datadir)/gdbtcl/images2 ; \
> - $(SHELL) $(srcdir)/../mkinstalldirs $(datadir)/gdbtcl/help \
> - $(datadir)/gdbtcl/help/images \
> - $(datadir)/gdbtcl/help/trace ; \
> - cd $(srcdir)/gdbtk/library ; \
> - for i in *.tcl *.ith *.itb images/*.gif images2/*.gif images/icons.txt images2/icons.txt tclIndex help/*.html help/trace/*.html help/trace/index.toc he
> lp/images/*.gif; \
> - do \
> - $(INSTALL_DATA) $$i $(datadir)/gdbtcl/$$i ; \
> - done ;
> @$(MAKE) DO=install "DODIRS=$(SUBDIRS)" $(FLAGS_TO_PASS) subdir_do
Again, not GNU/Linux/PPC specific. I think that should be split out
into a separate install target. A new CONFIG_INSTALL variable would
then hook it in. (making any sense?)
Thanks for these,
enjoy,
Andrew
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: toddpw@windriver.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Readline and -DMINIMAL
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312326.SAA07189@indy.delorie.com>
References: <200003281230.EAA15638@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00850.html
Content-length: 1146
> I have just discovered to my horror that the upgrade to Readline 2.2 in
> GDB 4.18 has completely eradicated support for the MINIMAL #define, and
> provides no alternative -- it simply assumes BSD style ttys and falls
> over dead if those aren't supported.
I don't think this is true. If you have termios, most of the code
simply works, except that you need to deal with the tputs and its ilk
here and there.
> Does anyone know the story on this one? Is there a stub library that
> is used for Cygwin and DJGPP ?
DJGPP doesn't have the termcap capability yet. Instead, the readline
sources have a few DJGPP-specific hacks to make it work.
> I really do not want to hack all the #ifdef MINIMAL stuff back in, but
> since I build direct on windows I need to shut up all the code that tries
> to use sgtty or termios.
I would be interested in making Readline work reasonably well,
including command-line editing etc., on non-Unix systems. As I said,
it currently works with DJGPP, but requires a small number of ugly
#ifdef's, and some functionality, like arrow keys, isn't supported,
which annoys DJGPP users who aren't hooked on Emacs.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B5EEDB.8A8F2DD8@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-q1/msg00414.html
Content-length: 2275
FYI,
The current behavior is determined by gdbarch.c:
o it starts in auto mode using
TARGET_BYTE_ORDER_DEFAULT as an
initial value or (chosen arbitrarily)
BIG_ENDIAN as the next best guess.
o as soon as GDB encounters a binary
it pokes around the bfd file to determine
the endianess and uses that (provided things
are still auto).
To the best of my knowledge, no one has seriously investigated how to
set up an interface where the target determines architectural
information (such as endianess).
As for the current problem:
$ arm-elf-gdb
GNU gdb 4.18
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT
2.11a)
Rebuilt on Apr 1 1998 at 00:43:57
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently big endian)
$ ~/gdb-000222/gdb/gdb
GNU gdb 000222
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT
2.11a)
Rebuilt on Apr 1 1998 at 00:43:57
Serial Rate: 9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently little endian)
it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
wrong place.
enjoy,
Andrew
Fernando Nasser wrote:
>
> Grant Edwards wrote:
> >
> > I had assumed that gdb was detecting the endianness of the
> > target already (before today, I didn't know it was user
> > selectable). I'll take a look at make the "auto" mode pay
> > attention to the target hardware indication. One could then
> > generate a warning if the endiannes of the target and the
> > endianness of a file being loaded disagree.
> >
> Good idea. If the endianess is set to auto, then you set it appropriately.
> If not, and it differs from the target, a warning is in order.
> You got no indication at all that something was wrong.
>
> --
> Fernando Nasser
> Red Hat - Toronto E-Mail: fnasser@cygnus.com
> 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
> Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From RDBrown@mira.net Tue Jan 02 05:37:00 2001
From: RDBrown@mira.net
To: gdb@sources.redhat.com, binutils@sources.redhat.com
Cc: ac131313@cygnus.com, philb@gnu.org
Subject: Re: Preferred format of Copyright statement
Date: Tue, 02 Jan 2001 05:37:00 -0000
Message-id: <E14DcEz-00007K-00@urtur>
References: <40D1CB7FA1EAD311BD610008C733141C1DE0E8@aus-msg-02.au.pmsc.com>
X-SW-Source: 2001-01/msg00000.html
Content-length: 1752
> For the patches supplied I found it easiest to run the script,
> correct the (few) errors it diagnosed and then walk through the changes
> doing some minor reformatting. The ChangeLog entries took almost as
> long. Since the changes are mainly in comments a big bang approach is
> less risky than for PARAMS. ...
If a binutils release is due soon and this is worth doing before
the release I'd better move. Or would it be better to wait until
the early Feb and the binutils release code freeze before standardizing
Copyright statements?
> I need to submit a patch to automake which has and generates
> an embedded year range.
(Automake development sources have been updated.)
> From: Andrew Cagney
...
> Sent: Tuesday, September 26, 2000 6:08 AM
> Subject: Re: Preferred format of Copyright statement
> > > I know this has a tendency to line-wrap, but so what? No human will
> > > ever care. So we might as well make it completely correct.
> > Ok, will produce that form.
> > Given that the first attempt over gdb
> > gives a patch file of ~900k touching 1725 files, would it be more useful
> > to provide patches for the few percent of cases needing manual fixes and
> > provide the script to be run when the maintainer finds it convenient?
> > Or should it only fix those with ranges or 2-digit years and leave (C)
> > removal where the year list is Ok?
> >
> > (Trying to conserve maintainer think time, not be a WOFTAM).
> (Yes I know your e-mail was posted a month ago :-().
...
> ... You won't need maintainer approval for this
> change. Just give a weeks notice on the big jumbo change.
=> move into the late 1990s and start using CVS with a temporary
write permission? Both gdb & binutils in one hit?
Regards,
Rodney Brown
From pb@futuretv.com Tue Jan 02 05:40:00 2001
From: Philip Blundell <pb@futuretv.com>
To: RDBrown@mira.net, RodneyBrown@mynd.com
Cc: gdb@sources.redhat.com, binutils@sources.redhat.com, ac131313@cygnus.com
Subject: Re: Preferred format of Copyright statement
Date: Tue, 02 Jan 2001 05:40:00 -0000
Message-id: <E14DRfe-0004fg-00@pig.labs.futuretv.com>
References: <E14DcEz-00007K-00@urtur>
X-SW-Source: 2001-01/msg00001.html
Content-length: 363
In message < E14DcEz-00007K-00@urtur >, RDBrown@mira.net writes:
>If a binutils release is due soon and this is worth doing before
>the release I'd better move. Or would it be better to wait until
>the early Feb and the binutils release code freeze before standardizing
>Copyright statements?
As far as I'm concerned, you might as well do it now.
Thanks
p.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Updated MAINTAINERS file - work in progress
2000-04-01 0:00 Updated MAINTAINERS file - work in progress Andrew Cagney
@ 2000-04-01 0:00 ` Kevin Buettner
2000-04-01 0:00 ` Andrew Cagney
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Buettner @ 2000-04-01 0:00 UTC (permalink / raw)
To: Andrew Cagney, GDB Discussion
[-- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01 0:00 Updated MAINTAINERS file - work in progress Andrew Cagney
2000-04-01 0:00 ` Kevin Buettner
2000-04-01 0:00 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox