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
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
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
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 unwi
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
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
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
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 thin
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
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 assum
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, 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
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 _b_f
> __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
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
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, 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
> >
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 poin
> 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 definitio
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 th
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 a
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 wher
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 defau
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
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
25 matches
Mail list logo
