* [RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF
@ 2005-06-03 23:59 Joel Brobecker
2005-06-13 3:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Joel Brobecker @ 2005-06-03 23:59 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
Hello,
A customer of ours reported that they were unable to break on certain
symbols unless the program be started. Here is the GDB output we get:
(gdb) break __gnat_raise_nodefer_with_msg
Cannot break on '__gnat_raise_nodefer_with_msg' without a running program.
This is where the problem is:
| int
| hppa_pc_requires_run_before_use (CORE_ADDR pc)
| {
| /* Sometimes we may pluck out a minimal symbol that has a negative address.
|
| An example of this occurs when an a.out is linked against a foo.sl.
| The foo.sl defines a global bar(), and the a.out declares a signature
| for bar(). However, the a.out doesn't directly call bar(), but passes
| its address in another call.
|
| If you have this scenario and attempt to "break bar" before running,
| gdb will find a minimal symbol for bar() in the a.out. But that
| symbol's address will be negative. What this appears to denote is
| an index backwards from the base of the procedure linkage table (PLT)
| into the data linkage table (DLT), the end of which is contiguous
| with the start of the PLT. This is clearly not a valid address for
| us to set a breakpoint on.
|
| Note that one must be careful in how one checks for a negative address.
| 0xc0000000 is a legitimate address of something in a shared text
| segment, for example. Since I don't know what the possible range
| is of these "really, truly negative" addresses that come from the
| minimal symbols, I'm resorting to the gross hack of checking the
| top byte of the address for all 1's. Sigh. */
|
| return (!target_has_stack && (pc & 0xFF000000));
| }
The problem is that the program built by our customer is large enough
that the address of certain symbol exceeds 0xFFFFFF, and hence triggers
the condition above.
But the condition above doesn't correspond to the comment. We think it
is an error, although it's always hard to tell with a hack. Anyway,
if changed the check to make sure that *all* bits in the top byte are
1's before forcing the user to start the program for this breakpoint.
This fixes the problem.
2005-06-03 Joel Brobecker <brobecker@adacore.com>
* hppa-tdep.c (hppa_pc_requires_run_before_use): Really test all
bits in of type byte in address.
Tested on hppa-hpux, no regression.
OK to apply?
Thanks,
--
Joel
[-- Attachment #2: hppa-tdep.c.diff --]
[-- Type: text/plain, Size: 681 bytes --]
Index: gdb/hppa-tdep.c
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.3/gdb/hppa-tdep.c,v
retrieving revision 1.15
diff -u -p -r1.15 hppa-tdep.c
--- gdb/hppa-tdep.c 19 Mar 2005 01:15:18 -0000 1.15
+++ gdb/hppa-tdep.c 3 Jun 2005 20:11:14 -0000
@@ -2401,7 +2401,7 @@ hppa_pc_requires_run_before_use (CORE_AD
minimal symbols, I'm resorting to the gross hack of checking the
top byte of the address for all 1's. Sigh. */
- return (!target_has_stack && (pc & 0xFF000000));
+ return (!target_has_stack && (pc & 0xFF000000) == 0xFF000000);
}
/* Return the GDB type object for the "standard" data type of data
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF
2005-06-03 23:59 [RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF Joel Brobecker
@ 2005-06-13 3:23 ` Daniel Jacobowitz
2005-06-13 13:45 ` Joel Brobecker
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Jacobowitz @ 2005-06-13 3:23 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
Oops, thought I reviewed this one earlier...
On Fri, Jun 03, 2005 at 04:59:18PM -0700, Joel Brobecker wrote:
> The problem is that the program built by our customer is large enough
> that the address of certain symbol exceeds 0xFFFFFF, and hence triggers
> the condition above.
>
> But the condition above doesn't correspond to the comment. We think it
> is an error, although it's always hard to tell with a hack. Anyway,
> if changed the check to make sure that *all* bits in the top byte are
> 1's before forcing the user to start the program for this breakpoint.
> This fixes the problem.
>
> 2005-06-03 Joel Brobecker <brobecker@adacore.com>
>
> * hppa-tdep.c (hppa_pc_requires_run_before_use): Really test all
> bits in of type byte in address.
>
> Tested on hppa-hpux, no regression.
> OK to apply?
Yes, I agree with your reading. This is OK.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF
2005-06-13 3:23 ` Daniel Jacobowitz
@ 2005-06-13 13:45 ` Joel Brobecker
0 siblings, 0 replies; 3+ messages in thread
From: Joel Brobecker @ 2005-06-13 13:45 UTC (permalink / raw)
To: gdb-patches
> > 2005-06-03 Joel Brobecker <brobecker@adacore.com>
> >
> > * hppa-tdep.c (hppa_pc_requires_run_before_use): Really test all
> > bits of top byte in address.
> >
> > Tested on hppa-hpux, no regression.
> > OK to apply?
>
> Yes, I agree with your reading. This is OK.
Thank you, checked in (with the changelog slightly rewritten in what
I hope is better English).
--
Joel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-06-13 13:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-03 23:59 [RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF Joel Brobecker
2005-06-13 3:23 ` Daniel Jacobowitz
2005-06-13 13:45 ` Joel Brobecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox