This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add __builtin_stack_top
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Mike Stump <mikestump at comcast dot net>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>
- Date: Tue, 4 Aug 2015 13:50:11 -0700
- Subject: Re: [PATCH] Add __builtin_stack_top
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOofnngGMTLWCe0fpXe56Y-psu8Ay7xujtBsBnKo9XyVJQ at mail dot gmail dot com> <C6ACFA8C-8ABF-47E7-9739-5298B87A0E7A at comcast dot net> <CAMe9rOro4BPFkG=qyBu6XYcfzc3YNqVqxKPrpC5dSxrtngxQTw at mail dot gmail dot com> <9652D8E5-C3B2-4C88-BC34-4591962D42D1 at comcast dot net> <CAMe9rOqKEJjTzP1jmzZ1tnZm9a1TXKSsUfnfw4OexNFNxfVPog at mail dot gmail dot com> <20150804174332 dot GN11083 at gate dot crashing dot org> <CAMe9rOq1axEMb34Zw2uudG6+5vjkiXKg7-i_8FRqMHL8DizqEw at mail dot gmail dot com> <20150804192913 dot GO11083 at gate dot crashing dot org> <CAMe9rOrrtDZxS2E3pD5DsUYox7ze1un0m8+LJ0Eo79BBLOsZgQ at mail dot gmail dot com> <20150804204506 dot GP11083 at gate dot crashing dot org>
On Tue, Aug 4, 2015 at 1:45 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Tue, Aug 04, 2015 at 01:00:32PM -0700, H.J. Lu wrote:
>> There is another issue with x86, maybe other targets. You
>> can't get the real stack top when stack is realigned and
>> -maccumulate-outgoing-args isn't used since ix86_expand_prologue
>> will create and return another stack frame for
>> __builtin_frame_address and __builtin_return_address.
>> It will be wrong for __builtin_stack_top, which should
>> return the real stack address.
>
> That's why I asked:
>
>> >> > You might have a reason why you want the entry stack address instead of the
>> >> > frame address, but you didn't really explain I think? Or I missed it.
>
> What would a C program do with this, that it cannot do with the frame
> address, that would be useful and cannot be much better done in straight
> assembler? Do you actually want to expose the argument pointer, maybe?
>
Yes, we want to use the argument pointer as shown in testcases
included in my patch.
--
H.J.