* Re: Linux sigtramp detection code moved to its proper place
[not found] ` <200003182227.RAA07055@indy.delorie.com>
@ 2000-04-01 0:00 ` Chris Faylor
0 siblings, 0 replies; 3+ messages in thread
From: Chris Faylor @ 2000-04-01 0:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: kettenis, kevinb, jimb, gdb-patches
On Sat, Mar 18, 2000 at 05:27:17PM -0500, Eli Zaretskii wrote:
>
>> I would be in favor of just creating an i386-linux-tdep.c and working
>> out the 8.3 issues later. Since there are already 8.3 issues in
>> the gdb source directory, adding one more is not going to aggravate
>> the problem unduly.
>
>I beg to disagree ;-). Let me explain why.
>
>What I intend to do to resolve the problem of file names clashing in
>the 8+3 namespace is to use the feature of DJTAR, an untar utility
>which comes with DJGPP, to rename files on the fly. To this end, I
>created a name-mapping file which specifies what files to rename and
>how; this file needs to be submitted to DJTAR when unpacking the
>distribution. I will make the file itself part of the distribution
>(so DJGPP users will need to unpack that special file first, and then
>the rest).
>
>I already spent a frustrating evening creating this name-mapping file;
>adding any new files that clash with existing files would require me
>to reproduce that file, possibly affecting other files as well.
>
>I respect the decision not to change any names before GDB 5.0 is
>released, but in the meantime could we please not add any new files
>whose names clash?
I am sympathetic to the plight of DOS users but this sounds like it is
something that could, in the short term, be handled by a program or perl
script fairly easily. If you actually have a solution for DOS, then
maybe that file or script should be part of the distribution and we
should not have to worry about this severe filename limitation.
IMO, in the long-term intelligent use of subdirectories should reduce
the size of all of the filenames.
cgf
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Scott Bambrough <scottb@netwinder.org>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch fallen through the cracks?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7C1C8.C4A8796A@cygnus.com>
References: <38C7ADD4.A6697C36@netwinder.org> <38C7BD11.9A8188CF@redhat.com>
X-SW-Source: 2000-q1/msg00624.html
Content-length: 692
Fernando Nasser wrote:
>
> Scott Bambrough wrote:
> >
> > Can someone approve this patch please. It shouldn't be a problem.
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00367.html
> >
>
> I would rather have it xfail'ed. It means that we know this test won't
> work on this platform but it is not ding what we want (this is what pass
> would mean).
I thought the patch was basically correct - the arm has that brain dead
wacko swapped double format.
The only suggestion I've had made would be to test a more generic
attribute indicating the exact format of a double V long rather than
test the arm target. Other platforms can have the same problem.
enjoy,
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix for target.c:do_target_signal_to_host()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A90F10.E61AF586@cygnus.com>
References: <200002142116.e1ELGrL06391@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00153.html
Content-length: 1447
Mark Kettenis wrote:
>
> Hi,
>
> I noticed that under Linux, if I send a RT signal N to the program I'm
> debugging, GDB actually sends signal N - 1, e.g. if you continue with
>
> signal SIG35
>
> GDB will tell you that the program terminated with SIG34.
>
> The appended patch fixes this.
If you add a comment noting that:
o TARGET_SIGNAL_REALTIME_32 isn't
contigious with TARGET_SIGNAL_REALTIME_32
o TARGET_SIGNAL_REALTIME_33 is 33 by defintion.
then it can go straight in.
Andrew
>
> Mark
>
> 2000-02-14 Mark Kettenis <kettenis@gnu.org>
>
> * target.c (do_target_signal_to_host): Do not use REALTIME_LO in
> the conversion of the signal number. TARGET_SIGNAL_REALTIME_33 is
> 33 by definition, whereas REALTIME_LO might be 32 on systems that
> have SIG32 such as Linux.
>
> Index: gdb/target.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/target.c,v
> retrieving revision 1.2
> diff -u -r1.2 target.c
> --- gdb/target.c 2000/02/09 08:52:47 1.2
> +++ gdb/target.c 2000/02/14 21:09:27
> @@ -2061,7 +2061,7 @@
> && oursig <= TARGET_SIGNAL_REALTIME_63)
> {
> int retsig =
> - (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + REALTIME_LO;
> + (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + 33;
> if (retsig < REALTIME_HI)
> return retsig;
> }
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: hash tables for msymbols
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npzosbejsi.fsf@zwingli.cygnus.com>
References: <87aeowo9jq.fsf@cygnus.com> <npr9drfz3b.fsf@zwingli.cygnus.com> <200003032252.OAA01491@ferrule.cygnus.com>
X-SW-Source: 2000-q1/msg00550.html
Content-length: 262
> I don't have write permission for gdb on sourceware. Nor do I want it
> right now. My gdb hacking time was a one-time-only fluke (more or
> less).
Oops. I'll commit it then. I'll look over Keith's fix, too. (I
thought everything was initialized, but...)
From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: thumb_skip_prologue too adventurous
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D5389B.6A481BFA@redhat.co.uk>
References: <38D3FFC8.32082A85@redhat.co.uk> <38D40052.AF731E81@redhat.co.uk> <38D5064B.40AE9470@redhat.com>
X-SW-Source: 2000-q1/msg00787.html
Content-length: 4848
Fernando Nasser wrote:
> I am not sure if there isn't a better solution for this, but for now I
> would say that you should check your change in as an emergency fix.
I don't have checkin rights to the "src" repository, so I'd be grateful if
you could do this for me.
> I
> am assuming you ran the testsuite and it did not cause any regressions,
> right? (I don't think it will cause any)
Nope - no regressions.
> I may latter add another change to check first if there is information
> about the prologue end in the symbol table. I don't know why this was
> not checked before, I just noticed it now, looking at you patch.
Don't worry - it is checked, but it is done in arm_skip_prologue, before
thumb_skip_prologue is called.
> I wrote this thumb prologue scan code to match the new compiler (gcc)
> prologue generation. As everything is new, both Nick and I used the
> testsuite results to verify our work. The case you mention does not have
> a testsuite case. I wonder if you could add a test case?
I've never done a GDB testcase before, but here goes - I've attached one. It
runs at the end of break.exp. The complication is that we need to start
over, because the problematic programs are the ones compiled with
optimization. So we have to jump through all the same hoops as at the start
of the file. Some of this stuff might be overkill, but it definitely seems
to work.
I agree the addition of this test is A Good Thing as we've had these types
of problems before on other targets with optimized code.
Hope this helps. Obviously let me know if there are any problems with it.
Jifl
2000-03-19 Jonathan Larmour <jlarmour@redhat.co.uk>
* gdb.base/break.exp: Add new test for setting breakpoints on
optimized code so we can test breakpoints work even when function
prologues may be optimized away
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault
Index: gdb/testsuite/gdb.base/break.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/break.exp,v
retrieving revision 1.2
diff -u -5 -p -r1.2 break.exp
--- gdb/testsuite/gdb.base/break.exp 2000/02/16 00:11:07 1.2
+++ gdb/testsuite/gdb.base/break.exp 2000/03/19 20:26:34
@@ -799,10 +799,83 @@ proc test_next_with_recursion {} {
}
test_clear_command
test_next_with_recursion
+
+#********
+
+# build a new file with optimization enabled so that we can try breakpoints
+# on targets with optimized prologues
+
+set binfileo2 ${objdir}/${subdir}/${testfile}o2
+
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfileo2}" executable {debug additional_flags="-O2" }] != "" } {
+ gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if [get_compiler_info ${binfileo2}] {
+ return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfileo2}
+
+if [target_info exists gdb_stub] {
+ gdb_step_for_stub;
+}
+
+#
+# test break at function
+#
+gdb_test "break main" \
+ "Breakpoint.*at.* file .*$srcfile, line.*" \
+ "breakpoint function, optimized file"
+
+#
+# test break at function
+#
+gdb_test "break marker4" \
+ "Breakpoint.*at.* file .*$srcfile, line.*" \
+ "breakpoint small function, optimized file"
+
+#
+# run until the breakpoint at main is hit. For non-stubs-using targets.
+#
+if ![target_info exists use_gdb_stub] {
+ if [istarget "*-*-vxworks*"] then {
+ send_gdb "run vxmain \"2\"\n"
+ set timeout 120
+ verbose "Timeout is now $timeout seconds" 2
+ } else {
+ send_gdb "run\n"
+ }
+ gdb_expect {
+ -re "The program .* has been started already.*y or n. $" {
+ send_gdb "y\n"
+ exp_continue
+ }
+ -re "Starting program.*Breakpoint \[0-9\]+,.*main .*argc.*argv.* at .*$srcfile:75.*75\[\t \]+if .argc.* \{.*$gdb_prompt $"\
+ { pass "run until function breakpoint, optimized file" }
+ -re ".*$gdb_prompt $" { fail "run until function breakpoint, optimized file" }
+ timeout { fail "run until function breakpoint, optimized file (timeout)" }
+ }
+} else {
+ if ![target_info exists gdb_stub] {
+ gdb_test continue ".*Continuing\\..*Breakpoint \[0-9\]+, main \\(argc=.*, argv=.*, envp=.*\\) at .*$srcfile:75.*75\[\t \]+if .argc.*\{.*" "stub continue, optimized file"
+ }
+}
+
+#
+# run until the breakpoint at a small function
+#
+gdb_test continue "Continuing\\..*Breakpoint \[0-9\]+, marker4 \\(d=177601976\\) at .*$srcfile:51.*51\[\t \]+void.*marker4.*" \
+ "run until breakpoint set at small function, optimized file"
+
+
# Reset the default arguments for VxWorks
if [istarget "*-*-vxworks*"] {
set timeout 10
verbose "Timeout is now $timeout seconds" 2
send_gdb "set args main\n"
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: hash tables for msymbols
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000304235333.A4155@cygnus.com>
References: <87aeowo9jq.fsf@cygnus.com> <npr9drfz3b.fsf@zwingli.cygnus.com> <20000303182733.A2742@cygnus.com> <87vh328rze.fsf@cygnus.com>
X-SW-Source: 2000-q1/msg00517.html
Content-length: 393
On Sat, Mar 04, 2000 at 12:17:41PM -0700, Tom Tromey wrote:
>>>>>> "Chris" == Chris Faylor <cgf@cygnus.com> writes:
>Chris> I believe that Fred Fish has also come up with a similar
>Chris> "speedup" patch. I don't know compares to Tom's, though.
>
>His patch ignores the demangling problem. I believe it removes some
>gdb functionality.
Ah. That's right. Thanks for clarifying that.
cgf
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA Replace gdb/TODO with issues50
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <n1np56q0.fsf@dan.resnet.rochester.edu>
References: <38DAED11.C314EA48@cygnus.com>
X-SW-Source: 2000-q1/msg00976.html
Content-length: 547
Andrew Cagney <ac131313@cygnus.com> writes:
I'm all for that, i've taken care of everything with the word C++ or
exception in the TODO file already (thought not all of it is perfect
and in yet).
> Hello,
>
> I'd like to propose that the file gdb/TODO be emptied and then refilled
> with a heavily edited version of:
>
> http://sourceware.cygnus.com/gdb/issues50.html
>
> To the best of my knowledge large chunks of the existing TODO file are
> either wrong or irrelevant. I think starting from scratch would be more
> useful.
>
> Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D82684.89633B0B@apple.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> <38D7FDD1.D54DE1D8@cygnus.com>
X-SW-Source: 2000-q1/msg00892.html
Content-length: 483
Andrew Cagney wrote:
>
> "J.T. Conklin" wrote:
>
> > It looks like the changes to the directory entry require the latest
> > makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed,
> > makeinfo from texinfo-4.0 works.
>
> >From memory, the possibility of requiring texinfo 4.0 as part of
> building GDB 5 was considered and rejected :-(
Yeah, I have to revert - tried it on one of Apple's MkLinux systems,
which claims to have texinfo 3.9, and it fell down too.
Stan
From dj@delorie.com Sat Apr 01 00:00:00 2000
From: DJ Delorie <dj@delorie.com>
To: shebs@apple.com
Cc: nickc@cygnus.com, jtc@redback.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Add support for WinCE toolchains
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002230024.TAA11216@envy.delorie.com>
References: <200002222350.PAA09035@elmo.cygnus.com> <38B32684.530F4F66@apple.com>
X-SW-Source: 2000-q1/msg00315.html
Content-length: 435
> This should get a special mention in gdb/NEWS, and ideally in README
> also; this is one of those situations where you'll be glad you
> forestalled a slew of complaints and bug reports by documenting it
> in several places.
Is it acceptable to add notes to configure, so that if you said
"./configure --target=arm-pe" it could print out "Note: if you wanted
Windows CE, use arm-wince-pe instead" ? Maybe in the toplevel configure?
From tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: breakpoint range doc patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001162255.OAA06804@ferrule.cygnus.com>
References: <200001162232.RAA08484@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00020.html
Content-length: 320
>>>>> "David" == David Taylor <taylor@cygnus.com> writes:
David> I'm not the maintainer for gdb/doc/gdb.texinfo, nor for
David> gdb/breakpoint.c (and this change is improving the
David> documentation of functionality implemented by that file), but I
David> approve it.
That's good enough for me.
I checked it in.
Tom
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-patches@sourceware.cygnus.com
Subject: Re: regression analysis: gdb.sum postprocessing script
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DEFEB1.EB573B72@cygnus.com>
References: <Pine.LNX.4.10.10003241103440.15236-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg01046.html
Content-length: 910
Jimmy Guo wrote:
>
> Here is a Perl script I wrote to postprocess one or more gdb.sum files
> and provide a complete dejagnu test outcome summary (or diff if more
> than one gdb.sum files are given). It's most useful if you want to have
> a complete view of regression status between two source trees and/or if
> you set up your testing to run multiple passes (to see how a test point
> behaves in different passes), however you can use it just on one test
> run's gdb.sum file and play around with the options to get test outcome
> presented in a much organized and useful way than going through the flat
> gdb.sum file.
I have a personal preference for keeping perl scripts out of the main
GDB sources :-(
Now if someone rewrote it to use either TCL, DEJAGNU or SH then I'd have
to think about it again - they are required to run the testsuite.
Perhaps a link/entry on the web page or ftp site.
Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: pes@regent.e-technik.tu-muenchen.de
Subject: Re: RFA: infrun.c, breakpoint.c: Kludge for Solaris x86 hardware watchpoint support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E13FD7.38E@cygnus.com>
References: <200003130947.KAA07528@reisser.regent.e-technik.tu-muenchen.de> <38E132C8.454C@cygnus.com>
X-SW-Source: 2000-q1/msg01097.html
Content-length: 215
Michael Snyder wrote:
> BTW, next time could you also include the ChangeLog entry
> in the diffs?
Oops, I stand corrected. I guess omitting the ChangeLog
from the diffs is the policy. Sorry for the confusion.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFD: printcmd.c: Changing output width of p/a and x/a
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D5EB6E.61C7D7D1@cygnus.com>
References: <200003072113.WAA26267@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00807.html
Content-length: 1675
"Peter.Schauer" wrote:
> Would you expect
>
> (gdb) p/a (char)-1
(I guess you mean ``(signed char) -1''
>
> to yield
>
> $1 = 0xff (truncation to length of value, will cause testsuite
> regressions, which have to be adressed by changing
> the expect patterns)
> or
>
> $1 = 0xffffffff (truncation to size of pointer)
I suspect the latter. The value is being printed as if it were being
interpreted as an address (but I'm not the CLI expert).
>
> Here is a patch to truncate to the size of a pointer, please let me know
> if you want this to be changed to truncate to the length of the value.
>
> 2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> * printcmd.c (print_scalar_formatted): Truncate addresses to the
> size of a target pointer before passing them to print_address.
>
> *** ./printcmd.c.orig Sun Mar 5 17:35:36 2000
> --- ./printcmd.c Tue Mar 7 19:59:46 2000
> ***************
> *** 443,449 ****
> break;
>
> case 'a':
> ! print_address (unpack_pointer (type, valaddr), stream);
> break;
>
> case 'c':
> --- 443,455 ----
> break;
>
> case 'a':
> ! {
> ! /* Truncate address to the size of a target pointer. */
> ! CORE_ADDR addr = unpack_pointer (type, valaddr);
> ! if (TARGET_PTR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
> ! addr &= ((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1;
> ! print_address (addr, stream);
> ! }
> break;
I'd include a comment noteing that shifting by
sizeof(CORE_ADDR)*HOST_CHAR_BIT is dangerous.
Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 5.0 2000-03-05
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000306094553.B28105@lucon.org>
References: <38C2320A.E2134B29@cygnus.com> <20000305094341.A10426@lucon.org> <br9dojaan.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00540.html
Content-length: 1913
On Mon, Mar 06, 2000 at 09:08:48AM -0800, Jim Kingdon wrote:
> > Linux people are looking for something better than gdb 4.17.0.1x to
> > debug Linuxthreads. It will be very disappointing if 5.0 fails to do
> > so.
>
> True, it would be disappointing. Anyway, here is my attempt to
> summarize what is up with Linux (based of course on
> http://sourceware.cygnus.com/gdb/issues50.html ). In case it isn't
> obvious, it is up to Linux folks (HJ/JimB/MarkK/me/whoever to) get
> fixes checked in, we don't want to keep "5.0 release central" (Andrew)
> waiting.
I may be able to spend sometime on it next week.
>
> * Spurious SIGTRAP bug. No one has diagnosed this bug as far as I
> know, although JimB was working on it. This one is probably the most
> serious.
Do you have URL for the bug report.
>
> * lin-thread cannot handle thread exit. Should we think about
> disabling lin-thread in favor of linux-thread for 5.0? Or to put it
> another way, has lin-thread gotten enough testing? There might
I don't think so.
> be other variations on this theme, such as a note in the
> documentation about how deleting/renaming libthread_db might be a
> workaround, although I'm not sure that really helps much.
I think it is a good ide for 5.0.
>
> * dlclose(). Any reactions MarkK? Or JimB? Note that issues50.html
> points to a withdrawn patch; the most recent is:
> http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00454.html
>
> * 2.0.x kernel patch. MarkK? issues50.html points to the latest
> patch on this as far as I know:
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00294.html
>
> * hardware watchpoints. Does not strike me as important for 5.0 as
> the above, but if someone has time, should be worth a review. It is
> nice to see some patches out there.
I have some old patches for it. I will work on it when I find time
next week.
H.J.
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: RFA: Patch to blockframe.c, frame.h, arm-tdep.c and fr30-tdep.c (prologue cache)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ACA4D6.993AFF74@cygnus.com>
X-SW-Source: 2000-q1/msg00240.html
Content-length: 8728
I believe the following fixes a bug found by Elena.
Fernando
2000-02-17 Fernando Nasser <fnasser@totem.to.cygnus.com>
* blockframe.c (check_prologue_cache, save_prologue_cache,
flush_prologue_cache): Slightly improved version of a prologue
cache
used by some targets. Here there is a flush mechanism so we
never use
stale data.
* frame.h: Prototypes for the above functions.
* arm-tdep.c (check_prologue_cache, save_prologue_cache):
Deleted.
Moved (with changes) to blockframe.c.
--
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
Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
retrieving revision 1.1.1.11
diff -c -p -r1.1.1.11 blockframe.c
*** blockframe.c 1999/12/22 21:45:03 1.1.1.11
--- blockframe.c 2000/02/18 01:38:15
*************** flush_cached_frames ()
*** 269,274 ****
--- 269,275 ----
current_frame = NULL; /* Invalidate cache */
select_frame (NULL, -1);
+ flush_prolog_cache (); /* Invalidate prologue cache as well. */
annotate_frames_invalid ();
}
*************** reinit_frame_cache ()
*** 284,289 ****
--- 285,354 ----
{
select_frame (get_current_frame (), 0);
}
+ }
+
+ /* Check if prologue for this frame's PC has already been scanned. If
+ it has, copy the relevant information about that prologue and
+ return non-zero. Otherwise do not copy anything and return zero.
+
+ The information saved in the cache includes:
+ * the frame register number;
+ * the size of the stack frame;
+ * the offsets of saved regs (relative to the old SP); and
+ * the offset from the stack pointer to the frame pointer
+
+ The cache contains only one entry, since this is adequate for the
+ typical sequence of prologue scan requests we get. When performing
+ a backtrace, GDB will usually ask to scan the same function twice
+ in a row (once to get the frame chain, and once to fill in the
+ extra frame information). */
+
+ static struct frame_info prologue_cache;
+ static int prologue_cache_valid = 0; /* Indicate if contents are
valid. */
+
+ static int
+ check_prologue_cache (struct frame_info *fi)
+ {
+ int i;
+
+ if ((prolog_cache_valid)
+ && (fi->pc == prologue_cache.pc))
+ {
+ fi->framereg = prologue_cache.framereg;
+ fi->framesize = prologue_cache.framesize;
+ fi->frameoffset = prologue_cache.frameoffset;
+ for (i = 0; i <= NUM_REGS; i++)
+ fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
+ return 1;
+ }
+ else
+ return 0;
+ }
+
+ /* Copy the prologue information from fi to the prologue cache. */
+
+ static void
+ save_prologue_cache (struct frame_info *fi)
+ {
+ int i;
+
+ prologue_cache.pc = fi->pc;
+ prologue_cache.framereg = fi->framereg;
+ prologue_cache.framesize = fi->framesize;
+ prologue_cache.frameoffset = fi->frameoffset;
+
+ for (i = 0; i <= NUM_REGS; i++)
+ prologue_cache.fsr.regs[i] = fi->fsr.regs[i];
+
+ prologue_cache_valid = 1;
+ }
+
+ /* Flush the prologue cache. */
+
+ static void
+ flush_prologue_cache ()
+ {
+ prologue_cache_valid = 0;
}
/* Return nonzero if the function for this frame lacks a prologue.
Many
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.1.1.11
diff -c -p -r1.1.1.11 frame.h
*** frame.h 2000/02/02 00:21:06 1.1.1.11
--- frame.h 2000/02/18 01:38:15
*************** extern void flush_cached_frames PARAMS (
*** 181,186 ****
--- 181,191 ----
extern void reinit_frame_cache PARAMS ((void));
+ extern static int check_prologue_cache PARAMS ((struct frame_info *));
+
+ extern static void save_prologue_cache PARAMS ((struct frame_info *));
+
+ extern static void flush_prologue_cache PARAMS ((void));
#ifdef FRAME_FIND_SAVED_REGS
/* XXX - deprecated */
Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.3
diff -c -p -r1.3 arm-tdep.c
*** arm-tdep.c 2000/02/17 19:51:04 1.3
--- arm-tdep.c 2000/02/18 01:38:16
*************** thumb_scan_prologue (struct frame_info *
*** 576,635 ****
}
}
- /* Check if prologue for this frame's PC has already been scanned. If
- it has, copy the relevant information about that prologue and
- return non-zero. Otherwise do not copy anything and return zero.
-
- The information saved in the cache includes:
- * the frame register number;
- * the size of the stack frame;
- * the offsets of saved regs (relative to the old SP); and
- * the offset from the stack pointer to the frame pointer
-
- The cache contains only one entry, since this is adequate for the
- typical sequence of prologue scan requests we get. When performing
- a backtrace, GDB will usually ask to scan the same function twice
- in a row (once to get the frame chain, and once to fill in the
- extra frame information). */
-
- static struct frame_info prologue_cache;
-
- static int
- check_prologue_cache (struct frame_info *fi)
- {
- int i;
-
- if (fi->pc == prologue_cache.pc)
- {
- fi->framereg = prologue_cache.framereg;
- fi->framesize = prologue_cache.framesize;
- fi->frameoffset = prologue_cache.frameoffset;
- for (i = 0; i <= NUM_REGS; i++)
- fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
- return 1;
- }
- else
- return 0;
- }
-
-
- /* Copy the prologue information from fi to the prologue cache. */
-
- static void
- save_prologue_cache (struct frame_info *fi)
- {
- int i;
-
- prologue_cache.pc = fi->pc;
- prologue_cache.framereg = fi->framereg;
- prologue_cache.framesize = fi->framesize;
- prologue_cache.frameoffset = fi->frameoffset;
-
- for (i = 0; i <= NUM_REGS; i++)
- prologue_cache.fsr.regs[i] = fi->fsr.regs[i];
- }
-
-
/* This function decodes an ARM function prologue to determine:
1) the size of the stack frame
2) which registers are saved on it
--- 576,581 ----
Index: fr30-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/fr30-tdep.c,v
retrieving revision 1.1.1.4
diff -c -p -r1.1.1.4 fr30-tdep.c
*** fr30-tdep.c 1999/07/07 20:06:09 1.1.1.4
--- fr30-tdep.c 2000/02/18 01:38:16
*************** _initialize_fr30_tdep ()
*** 251,318 ****
tm_print_insn = print_insn_fr30;
}
- /* Function: check_prologue_cache
- Check if prologue for this frame's PC has already been scanned.
- If it has, copy the relevant information about that prologue and
- return non-zero. Otherwise do not copy anything and return zero.
-
- The information saved in the cache includes:
- * the frame register number;
- * the size of the stack frame;
- * the offsets of saved regs (relative to the old SP); and
- * the offset from the stack pointer to the frame pointer
-
- The cache contains only one entry, since this is adequate
- for the typical sequence of prologue scan requests we get.
- When performing a backtrace, GDB will usually ask to scan
- the same function twice in a row (once to get the frame chain,
- and once to fill in the extra frame information).
- */
-
- static struct frame_info prologue_cache;
-
- static int
- check_prologue_cache (fi)
- struct frame_info *fi;
- {
- int i;
-
- if (fi->pc == prologue_cache.pc)
- {
- fi->framereg = prologue_cache.framereg;
- fi->framesize = prologue_cache.framesize;
- fi->frameoffset = prologue_cache.frameoffset;
- for (i = 0; i <= NUM_REGS; i++)
- fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
- return 1;
- }
- else
- return 0;
- }
-
-
- /* Function: save_prologue_cache
- Copy the prologue information from fi to the prologue cache.
- */
-
- static void
- save_prologue_cache (fi)
- struct frame_info *fi;
- {
- int i;
-
- prologue_cache.pc = fi->pc;
- prologue_cache.framereg = fi->framereg;
- prologue_cache.framesize = fi->framesize;
- prologue_cache.frameoffset = fi->frameoffset;
-
- for (i = 0; i <= NUM_REGS; i++)
- {
- prologue_cache.fsr.regs[i] = fi->fsr.regs[i];
- }
- }
-
-
/* Function: scan_prologue
Scan the prologue of the function that contains PC, and record what
we find in PI. PI->fsr must be zeroed by the called. Returns the
--- 251,256 ----
From taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] utils.c should not assume that sizeof(long) == 32
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201738.MAA22436@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00817.html
Content-length: 1306
Date: Sat, 18 Mar 2000 15:08:04 -0700
From: Kevin Buettner <kevinb@cygnus.com>
The following patch fixes a problem on IA-64 where I was seeing the
following behavior...
(gdb) print 3.0 * 4.0
$1 = 24
(gdb) print 2.0
$2 = 4
This bug was also responsible for a number of testsuite failures.
May I check this in?
Approved.
* utils.c (floatformat_from_doublest): Don't assume that a long
will be exactly 32 bits in length.
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.4
diff -u -p -r1.4 utils.c
--- utils.c 2000/03/04 02:23:06 1.4
+++ utils.c 2000/03/18 21:43:59
@@ -2771,7 +2771,7 @@ floatformat_from_doublest (fmt, from, to
mant_bits = mant_bits_left < 32 ? mant_bits_left : 32;
mant *= 4294967296.0;
- mant_long = (unsigned long) mant;
+ mant_long = ((unsigned long) mant) & 0xffffffffL;
mant -= mant_long;
/* If the integer bit is implicit, then we need to discard it.
@@ -2782,6 +2782,7 @@ floatformat_from_doublest (fmt, from, to
&& fmt->intbit == floatformat_intbit_no)
{
mant_long <<= 1;
+ mant_long &= 0xffffffffL;
mant_bits -= 1;
}
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jimb@zwingli.cygnus.com
Cc: kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003182227.RAA07058@indy.delorie.com>
References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <npsnxp8ix6.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00773.html
Content-length: 622
> *** gdb/Makefile.in 2000/03/16 10:23:38 1.13
> --- gdb/Makefile.in 2000/03/17 19:59:40
> ***************
> *** 1063,1068 ****
> --- 1063,1069 ----
> i386-tdep.c i386b-nat.c i386mach-nat.c i386v-nat.c i386-linux-nat.c \
> i386aix-nat.c i386m3-nat.c i386v4-nat.c i386ly-tdep.c \
> i387-tdep.c \
> + i386-linux-tdep.c \
> i960-tdep.c \
> infptrace.c inftarg.c irix4-nat.c irix5-nat.c isi-xdep.c \
> lynx-nat.c m3-nat.c \
I see you already added the new file. Sigh... Is it possible to find
a different name for it, one which won't clash with i386-linux-nat.c?
How about i386linux-tdep.c, for example?
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] testsuite changes needed for AIX 4.3
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A9E4F9.514007E1@apple.com>
References: <1000215230816.ZM2175@ocotillo.lan>
X-SW-Source: 2000-q1/msg00162.html
Content-length: 845
Kevin Buettner wrote:
>
> I hereby reqest approval for committing the following changes:
>
> * gdb.base/pointers.c (usevar): New function.
> (main): Make sure that global variables v_int_pointer2, rptr,
> and y are all referenced someplace in the program by calling
> usevar() on them. [Some linkers delete symbols which are
> never referenced. The space remains, but there's no way to
> get a (symbolic) handle on the variable from the debugger.]
>
> * gdb.base/scope.exp: For powerpc-*-*, xfail the same tests
> that rs6000-*-* does.
This looks reasonable to me, with the same question as Mark Kettenis
raises: are the xfails unconditional because the tests fail whether
xlc or gcc is used as the compiler? If they pass with xlc, then you
need to test gcc_compiled.
Stan
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: i386/tm-nsbd.h, i386/nm-nbsd.h
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m66uggiur.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00871.html
Content-length: 1734
I submit the enclosed patch for approval. These changes enable
floating point register support on NetBSD/i386.
--jtc
2000-03-21 J.T. Conklin <jtc@redback.com>
* i386/tm-nbsd.h (NUM_REGS): Removed.
(HAVE_I387_REGS): Defined.
* i386/nm-nbsd.h (FLOAT_INFO): Removed.
Index: tm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 tm-nbsd.h
*** tm-nbsd.h 1999/07/07 20:13:21 1.1.1.2
--- tm-nbsd.h 2000/03/21 20:22:36
***************
*** 21,31 ****
#ifndef TM_NBSD_H
#define TM_NBSD_H
#include "i386/tm-i386bsd.h"
#include "tm-nbsd.h"
-
- #undef NUM_REGS
- #define NUM_REGS 16
#define JB_ELEMENT_SIZE sizeof(int) /* jmp_buf[_JBLEN] is array of ints */
#define JB_PC 0 /* Setjmp()'s return PC saved here */
--- 21,30 ----
#ifndef TM_NBSD_H
#define TM_NBSD_H
+ #define HAVE_I387_REGS
+
#include "i386/tm-i386bsd.h"
#include "tm-nbsd.h"
#define JB_ELEMENT_SIZE sizeof(int) /* jmp_buf[_JBLEN] is array of ints */
#define JB_PC 0 /* Setjmp()'s return PC saved here */
Index: nm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 nm-nbsd.h
*** nm-nbsd.h 1999/07/07 20:12:53 1.1.1.2
--- nm-nbsd.h 2000/03/21 20:22:36
***************
*** 24,31 ****
/* Get generic NetBSD native definitions. */
#include "nm-nbsd.h"
- /* #define FLOAT_INFO { i386_float_info(); } */
-
#define REGISTER_U_ADDR(addr, blockend, regno) \
(addr) = i386_register_u_addr ((blockend),(regno));
--- 24,29 ----
--
J.T. Conklin
RedBack Networks
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [Maint] Second testsuite maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D8C648.3FE00B1C@redhat.com>
References: <38D84B37.B90E15AB@cygnus.com> <38D8C5BA.20C4B77@redhat.com>
X-SW-Source: 2000-q1/msg00903.html
Content-length: 307
Sorry folks.
That was a personal message and I pressed the wrong button by mistake.
:-(
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] symtab.h, symfile.h, symfile.c, and solib.c changes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000321225350.ZM26428@ocotillo.lan>
X-SW-Source: 2000-q1/msg00881.html
Content-length: 8162
I just committed the following changes. I've built/run the test suite
on three platforms (linux/ia32, linux/ia64, linux/ppc) and all looks
well.
* symtab.h (MAX_SECTIONS, struct section_addr_info,
symbol_file_add): Move declarations from here...
* symfile.h: ...to here.
* solib.c (symbol_add_stub): Make symbol_file_add () aware of
all section addresses, not just .text.
* symfile.h, symfile.c (free_section_addr_info,
build_section_addr_info_from_section_table): New functions.
* symfile.h (MAX_SECTIONS): Increase value to 40.
* symfile.c (syms_from_objfile): Add bounds check prior to
accessing ``other'' array in a section_addr_info_struct.
Remove unused variable section_offsets.
(add_symbol_file_command): Remove unused variable text_addr.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.5
diff -u -p -r1.5 solib.c
--- solib.c 2000/03/17 20:12:23 1.5
+++ solib.c 2000/03/21 22:12:33
@@ -1155,6 +1155,7 @@ symbol_add_stub (arg)
{
register struct so_list *so = (struct so_list *) arg; /* catch_errs bogon */
CORE_ADDR text_addr = 0;
+ struct section_addr_info *sap;
/* Have we already loaded this shared object? */
ALL_OBJFILES (so->objfile)
@@ -1181,15 +1182,12 @@ symbol_add_stub (arg)
+ LM_ADDR (so);
}
- {
- struct section_addr_info section_addrs;
-
- memset (§ion_addrs, 0, sizeof (section_addrs));
- section_addrs.text_addr = text_addr;
-
- so->objfile = symbol_file_add (so->so_name, so->from_tty,
- §ion_addrs, 0, OBJF_SHARED);
- }
+ sap = build_section_addr_info_from_section_table (so->sections,
+ so->sections_end);
+ sap->text_addr = text_addr;
+ so->objfile = symbol_file_add (so->so_name, so->from_tty,
+ sap, 0, OBJF_SHARED);
+ free_section_addr_info (sap);
return (1);
}
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.2
diff -u -p -r1.2 symfile.c
--- symfile.c 2000/03/15 19:43:57 1.2
+++ symfile.c 2000/03/21 22:12:37
@@ -461,6 +461,58 @@ find_lowest_section (abfd, sect, obj)
*lowest = sect;
}
+
+/* Build (allocate and populate) a section_addr_info struct from
+ an existing section table. */
+
+extern struct section_addr_info *
+build_section_addr_info_from_section_table (const struct section_table *start,
+ const struct section_table *end)
+{
+ struct section_addr_info *sap;
+ const struct section_table *stp;
+ int oidx;
+
+ sap = xmalloc (sizeof (struct section_addr_info));
+ memset (sap, 0, sizeof (struct section_addr_info));
+
+ for (stp = start, oidx = 0; stp != end; stp++)
+ {
+ if (strcmp (stp->the_bfd_section->name, ".text") == 0)
+ sap->text_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".data") == 0)
+ sap->data_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".bss") == 0)
+ sap->bss_addr = stp->addr;
+
+ if (stp->the_bfd_section->flags & (SEC_ALLOC | SEC_LOAD)
+ && oidx < MAX_SECTIONS)
+ {
+ sap->other[oidx].addr = stp->addr;
+ sap->other[oidx].name = xstrdup (stp->the_bfd_section->name);
+ sap->other[oidx].sectindex = stp->the_bfd_section->index;
+ oidx++;
+ }
+ }
+
+ return sap;
+}
+
+
+/* Free all memory allocated by build_section_addr_info_from_section_table. */
+
+extern void
+free_section_addr_info (struct section_addr_info *sap)
+{
+ int idx;
+
+ for (idx = 0; idx < MAX_SECTIONS; idx++)
+ if (sap->other[idx].name)
+ free (sap->other[idx].name);
+ free (sap);
+}
+
+
/* Parse the user's idea of an offset for dynamic linking, into our idea
of how to represent it for fast symbol reading. This is the default
version of the sym_fns.sym_offsets function for symbol readers that
@@ -531,7 +583,6 @@ syms_from_objfile (objfile, addrs, mainl
int mainline;
int verbo;
{
- struct section_offsets *section_offsets;
asection *lower_sect;
asection *sect;
CORE_ADDR lower_offset;
@@ -738,7 +789,9 @@ syms_from_objfile (objfile, addrs, mainl
else if (strcmp (s->the_bfd_section->name, ".bss") == 0)
s_addr = addrs->bss_addr;
else
- for (i = 0; !s_addr && addrs->other[i].name; i++)
+ for (i = 0;
+ !s_addr && i < MAX_SECTIONS && addrs->other[i].name;
+ i++)
if (strcmp (s->the_bfd_section->name, addrs->other[i].name) == 0)
s_addr = addrs->other[i].addr; /* end added for gdb/13815 */
@@ -1460,7 +1513,6 @@ add_symbol_file_command (args, from_tty)
int from_tty;
{
char *name = NULL;
- CORE_ADDR text_addr;
int flags = OBJF_USERLOADED;
char *arg;
int expecting_option = 0;
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 symfile.h
--- symfile.h 1999/10/19 02:46:39 1.1.1.6
+++ symfile.h 2000/03/21 22:12:37
@@ -54,6 +54,29 @@ struct psymbol_allocation_list
int size;
};
+/* Define an array of addresses to accommodate non-contiguous dynamic
+ loading of modules. This is for use when entering commands, so we
+ can keep track of the section names until we read the file and
+ can map them to bfd sections. This structure is also used by
+ solib.c to communicate the section addresses in shared objects to
+ symbol_file_add (). */
+
+#define MAX_SECTIONS 40
+struct section_addr_info
+{
+ /* Sections whose names are always known to gdb. */
+ CORE_ADDR text_addr;
+ CORE_ADDR data_addr;
+ CORE_ADDR bss_addr;
+ /* Sections whose names are file format dependant. */
+ struct other_sections
+ {
+ CORE_ADDR addr;
+ char *name;
+ int sectindex;
+ } other[MAX_SECTIONS];
+};
+
/* Structure to keep track of symbol reading functions for various
object file types. */
@@ -162,6 +185,23 @@ syms_from_objfile PARAMS ((struct objfil
extern void
new_symfile_objfile PARAMS ((struct objfile *, int, int));
+
+extern struct objfile *
+symbol_file_add PARAMS ((char *, int, struct section_addr_info *, int, int));
+
+/* Build (allocate and populate) a section_addr_info struct from
+ an existing section table. */
+
+struct section_table;
+extern struct section_addr_info *
+build_section_addr_info_from_section_table (const struct section_table *start,
+ const struct section_table *end);
+
+/* Free all memory allocated by build_section_addr_info_from_section_table. */
+
+extern void
+free_section_addr_info (struct section_addr_info *);
+
extern struct partial_symtab *
start_psymtab_common PARAMS ((struct objfile *, struct section_offsets *,
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.3
diff -u -p -r1.3 symtab.h
--- symtab.h 2000/03/14 19:58:02 1.3
+++ symtab.h 2000/03/21 22:12:39
@@ -837,27 +837,6 @@ struct section_offsets
(sizeof (struct section_offsets) \
+ sizeof (((struct section_offsets *) 0)->offsets) * (SECT_OFF_MAX-1))
-/* Define an array of addresses to accommodate non-contiguous dynamic
- loading of modules. This is for use when entering commands, so we
- can keep track of the section names until we read the file and
- can map them to bfd sections. */
-
-#define MAX_SECTIONS 12
-struct section_addr_info
-{
- /* Sections whose names are always known to gdb. */
- CORE_ADDR text_addr;
- CORE_ADDR data_addr;
- CORE_ADDR bss_addr;
- /* Sections whose names are file format dependant. */
- struct other_sections
- {
- CORE_ADDR addr;
- char *name;
- int sectindex;
- } other[MAX_SECTIONS];
-};
-
/* Each source file or header is represented by a struct symtab.
These objects are chained through the `next' field. */
@@ -1436,9 +1415,6 @@ extern struct symtab *
extern void
clear_solib PARAMS ((void));
-
-extern struct objfile *
-symbol_file_add PARAMS ((char *, int, struct section_addr_info *, int, int));
/* source.c */
^ permalink raw reply [flat|nested] 3+ messages in thread