Mark Mitchell [EMAIL PROTECTED] writes:
I'd suggest we leave backtrace() aside, and just talk about
__builtin_frame_address(0), which does have well-defined semantics.
_b_f_a(0) is currently broken on ARM, and we all agree we should fix it.
I don't want to fan the flames here, but I'm not sure
Richard Sandiford wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I'd suggest we leave backtrace() aside, and just talk about
__builtin_frame_address(0), which does have well-defined semantics.
_b_f_a(0) is currently broken on ARM, and we all agree we should fix it.
I don't want to fan the
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
Richard E. asked what possible uses this function might have.
Obviously, GLIBC's backtrace() function is one, though I guess that's a
weak example, in that we all agree one should really be using unwind
information.
Which there is
Daniel Jacobowitz wrote:
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
Richard E. asked what possible uses this function might have.
Obviously, GLIBC's backtrace() function is one, though I guess that's a
weak example, in that we all agree one should really be using unwind
On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
Richard E. asked what possible uses this function might have.
Obviously, GLIBC's backtrace() function is one, though I guess that's a
weak
Daniel Jacobowitz wrote:
On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
Richard E. asked what possible uses this function might have.
Obviously, GLIBC's backtrace() function is one, though
Mark Mitchell [EMAIL PROTECTED] writes:
Richard Sandiford wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I'd suggest we leave backtrace() aside, and just talk about
__builtin_frame_address(0), which does have well-defined semantics.
_b_f_a(0) is currently broken on ARM, and we all agree we
On Thu, 2006-06-01 at 16:05, Mark Shinwell wrote:
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb, the frame pointer can access much less data on the stack
Mark Shinwell writes:
Mark If the hard frame pointer is forced by default, then targets which are
Mark particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark Since such targets would presumably not have to force reload to keep
Mark the frame pointer, then definitions of
David Edelsohn wrote:
Mark Shinwell writes:
Mark If the hard frame pointer is forced by default, then targets which are
Mark particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark Since such targets would presumably not have to force reload to keep
Mark the frame
On Fri, 2006-06-02 at 14:57, Mark Shinwell wrote:
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb,
On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
However when dealing with __builtin_frame_address, we must return the
correct value from this function no matter what the value of count. This
patch therefore forces use of a hard FP in such situations.
Eh? The manual explicitly says that
On Fri, Jun 02, 2006 at 04:20:21PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
However when dealing with __builtin_frame_address, we must return the
correct value from this function no matter what the value of count. This
patch therefore forces use of
__builtin_frame_address(n) is not required to work for any value other
than n=0. It's not clear what it means anyway on a function that
eliminates the frame pointer.
On ARM you *cannot* walk the stack frames without additional
information. Frames are private to each function and there is
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a backtrace
on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer
then you can walk the frames. Given this assumption I think it make sense to
have
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
backtrace
on Arm. However if you assume only Arm code code and
-fno-omit-frame-pointer
then you can
Richard Earnshaw wrote:
The only chance you have for producing a backtrace() is to have
unwinding information similar to that provided for exception unwinding.
This would describe to the unwinder how that frames code is laid out so
that it can unpick it.
I'd suggest we leave backtrace()
On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
backtrace
on Arm. However if you assume only Arm
On Friday 02 June 2006 16:44, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
On Fri, 2006-06-02 at 16:46, Mark Mitchell wrote:
Richard, I can't tell from your comments how you think _b_f_a(0) should
be implemented on ARM. We could use Mark's logic (forcing a hard frame
pointer), but stuff it into INITIAL_FRAME_ADDRESS_RTX. We could also
try to reimplement the thing
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but allow targets to define another macro
that will cause the
Mark Shinwell wrote:
Option (i), which is in all but name the solution 5 approach [1] proposed
last year, means that the count == 0 case is elevated to the same level
of importance as the count 0 cases, in line with the use in
backtrace (). The problem with this is that on platforms where the
Mark Shinwell wrote:
Hi,
I'd like to gather some opinions and advice on the expansion of
__builtin_frame_address, as discussed on gcc-patches last year [1, 2].
This centres on the following comment in expand_builtin_return_addr
arising from revision 103294 last year:
I've explicitly Cc'd
Hi,
I'd like to gather some opinions and advice on the expansion of
__builtin_frame_address, as discussed on gcc-patches last year [1, 2].
This centres on the following comment in expand_builtin_return_addr
arising from revision 103294 last year:
/* For a zero count, we don't care what frame
25 matches
Mail list logo
