Curious about gcc v4.1.2, x86 assembly, and stack overallocation
If I have the following code:
struct bob{
int a;
char b[8];
int c;
};
struct bob barker;
...
void sub1(unsigned int size){
int someflag=0;
struct bob dole;
memcpy(&dole.b,&barker.b,size);
}
let's say I call the code as sub(8) (the code is intentionally written
to allow overflows).
and I compile it with just plain "gcc -o test test.c", I get the
following assembly
08048427 :
8048427: 55 push %ebp
8048428: 89 e5 mov%esp,%ebp
804842a: 57 push %edi
804842b: 56 push %esi
804842c: 83 ec 20sub$0x20,%esp
804842f: c7 45 f4 00 00 00 00movl $0x0,0xfff4(%ebp)
8048436: 8d 45 e4lea0xffe4(%ebp),%eax
8048439: 83 c0 04add$0x4,%eax
804843c: 8b 55 08mov0x8(%ebp),%edx
804843f: 89 c7 mov%eax,%edi
8048441: be ac 96 04 08 mov$0x80496ac,%esi
8048446: fc cld
8048447: 89 d1 mov%edx,%ecx
8048449: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
804844b: 83 c4 20add$0x20,%esp
804844e: 5e pop%esi
804844f: 5f pop%edi
8048450: 5d pop%ebp
8048451: c3 ret
Now, the weird thing about this assembly to me, is that when I track
the usage of the stack, I can't help but notice that it seems like
about 3 words (0xC bytes) too many seem to get allocated with that sub
$0x20 instruction. That is to say, I have the someflag local variable,
which should take up 0x4 + the bob dole struct which is 0x10 = 0x14
bytes required for local variables. Further, we can see that the while
the address %ebp - 0x1C (start of dole) gets accessed, but %ebp -
0x20, 0x24, 0x28 also get allocated by that initial sub, but never get
touched.
I noticed also that when I replace the memcpy with a strcpy for
instance, while gdb will allocate space for the parameters to be
passed to strcpy, they're esp-relative accesses, rather than the
ebp-relative that one normally sees for local variables, BUT there is
still 3 extra words of data between the beginning of dole, and the
beginning of the stack parameters...so again, they never get touched!
(08048450 :
8048450: 55 push %ebp
8048451: 89 e5 mov%esp,%ebp
8048453: 83 ec 28sub$0x28,%esp
8048456: c7 45 fc 00 00 00 00movl $0x0,0xfffc(%ebp)
804845d: c7 44 24 04 d0 96 04movl $0x80496d0,0x4(%esp)
8048464: 08
8048465: 8d 45 eclea0xffec(%ebp),%eax
8048468: 83 c0 04add$0x4,%eax
804846b: 89 04 24mov%eax,(%esp)
804846e: e8 95 fe ff ff call 8048308 <[EMAIL PROTECTED]>
8048473: c9 leave
8048474: c3 ret)
Basically I'm just curious to understand why gcc adds this extra space.
Thanks
Gary Guy
Re: Curious about gcc v4.1.2, x86 assembly, and stack overallocation
gdb guy wrote: > If I have the following code: > > > Basically I'm just curious to understand why gcc adds this extra space. The stack pointer is always 16-aligned. Does that help? Andrew.
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
on 27/05/2008 13:50 Manuel López-Ibáñez said the following:
Please, open a bug report: http://gcc.gnu.org/bugzilla/
Manuel,
I looked through open GCC bugs and it seems that the following bugs are
very similar to what I report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
Should I still open a new one or maybe it's better to follow up on one
of those two.
And just in case, here's a better description of what I am reporting
(demonstration by comparison):
**
int main()
{
int int_x;
int int_y;
short short_x;
short short_y;
short_x += short_y;
short_x = short_x + short_y;
int_x += int_y;
int_x = int_x + int_y;
return 0;
}
**
$ g++ -Wconversion test-conv.cc -o test-conv
test-conv.cc: In function ‘int main()’:
test-conv.cc:8: warning: conversion to ‘short int’ from ‘int’ may alter
its value
test-conv.cc:9: warning: conversion to ‘short int’ from ‘int’ may alter
its value
$ g++ -dumpversion
4.3.0
2008/5/26 Andriy Gapon <[EMAIL PROTECTED]>:
If I write something like the following:
uint8_t x;
uint8_t y;
x ^= y;
and compile with gcc 4.3.0 with -Wconversion option, then I get the
following warning:
warning: conversion to 'unsigned char' from 'int' may alter its value
[-Wconversion]
While technically this warning is correct (because x and y are
implicitly advanced to "int"before actual xor operation), it seems that
it doesn't make much practical sense.
I think that this applies to all "assignment-by" operators working on
types shorter than int.
OTOH, proper implementation should be smart enough to warn about the
following:
uint8_t x;
uint16_t y;
x ^= y;
--
Andriy Gapon
--
Andriy Gapon
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
On Tue, May 27, 2008 at 11:29 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: > Should I still open a new one or maybe it's better to follow up on one of > those two. > > And just in case, here's a better description of what I am reporting > (demonstration by comparison): The warnings with the below code is correct because of how C/C++ define promotions. It is ^/|/& where the warnings are not correct and should be solved. Thanks, Andrew Pinski
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
on 27/05/2008 21:48 Andrew Pinski said the following: On Tue, May 27, 2008 at 11:29 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: Should I still open a new one or maybe it's better to follow up on one of those two. And just in case, here's a better description of what I am reporting (demonstration by comparison): The warnings with the below code is correct because of how C/C++ define promotions. It is ^/|/& where the warnings are not correct and should be solved. Thank you for the explanation! I didn't realize the difference. OTOH, do you think that those arithmetic warnings are practical (as opposed to being correct)? I understand the rules of the language(s) but honestly I expect the same behavior for short and for int in expressions like those. And in cases where I don't expect it I'll be careful about result type anyway. -- Andriy Gapon
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: > Thank you for the explanation! I didn't realize the difference. > > OTOH, do you think that those arithmetic warnings are practical (as opposed > to being correct)? I think so as the short int case has a defined overflow of the signed short type that is SHRT_MAX + 1 is defined while INT_MAX + 1 is not. -- Pinski
GCC 4.1 snapshots
At this point, we have three open release branches (4.1, 4.2, and 4.3) and trunk. Currently we are generating weekly snapshots for all four of these. A while ago we agreed, for a number of reasons, not to do any further GCC 4.1.x releases and the speed of changes on that branch has noticably slowed down. My recommendation in my very unoffical role as "carer of the snapshots" is to stop doing those weekly snapshots for the 4.1 branch, and I will be happy to roll a new snapshot upon request in case someone (like a GNU/Linux or BSD distribution would like to see one for their packages) in that case. If there is agreement, I am happy to take the appropriate technical steps. Thoughts? Gerald
Announcement: initial release of a coding rule checker for GCC
Hello all, In the context of the GlobalGCC project (http://www.ggcc.info, http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html) we are developing a facility for automatically enforcing coding rules. Coding rules codify "good programming practices" that improve reliability and maintainability in languages such as C or C++, known for containing many error-prone features (not to be confused with coding style-guides, even if the boundary is diffuse). You can find a more detailed explanation in http://www.ggcc.info/?q=codingrules This tool will be presented in the GCC Developers Summit 2008 in a few weeks, and can be downloaded and tested following the instructions found at http://www.ggcc.info/files/README-codingrules.txt We are using two Git repositories: one for a modified version of GCC (initially cloned from the http://git.infradead.org/gcc.git repo), and another for other files outside the GCC tree. The Ciao Prolog System is needed for running the checker. Our modified version of GCC can dump some information about a C++ program in the form of Prolog facts. Then, a Prolog engine is used for codifying coding rules and search the dumped data for violations of the rules. Very few rules are implemented right now but, hopefully, some more rules will be added in the next days/weeks. At time being, only structural information (classes, inheritance, methods, variables, types) is dumped, and only the middle-end of the compiler has been modified. We plan to extract information from the front-end(s) as well (e.g. templates, friend declarations, syntactic features) to enrich the rule definition language. Even sophisticated analysis done in some optimization passes could be profited for implementing some coding rules. We are using some Tracs for coordination and bug reporting, but we have still to define how to coordinate tracs for different git repos. If you are interested in the project I suggest to send me an e-mail. Regards, -- Guillem Marpons Universidad Politécnica de Madrid - Babel Group
Re: GCC 4.1 snapshots
On Tue, May 27, 2008 at 10:48 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > At this point, we have three open release branches (4.1, 4.2, and 4.3) > and trunk. Currently we are generating weekly snapshots for all four > of these. > > A while ago we agreed, for a number of reasons, not to do any further > GCC 4.1.x releases and the speed of changes on that branch has noticably > slowed down. > > My recommendation in my very unoffical role as "carer of the snapshots" > is to stop doing those weekly snapshots for the 4.1 branch, and I will > be happy to roll a new snapshot upon request in case someone (like a > GNU/Linux or BSD distribution would like to see one for their packages) > in that case. > > If there is agreement, I am happy to take the appropriate technical > steps. > > Thoughts? I'd rather close the 4.2 branch than the 4.1 one. Unfortunately the FSF has put us in a situation where we can't do any more 4.1 releases. Can we slow down the 4.1 snapshot interval to 4 weeks instead? Thanks, Richard.
Re: GCC 4.1 snapshots
On Tue, May 27, 2008 at 10:48 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > > My recommendation in my very unoffical role as "carer of the snapshots" > > is to stop doing those weekly snapshots for the 4.1 branch, and I will > > be happy to roll a new snapshot upon request in case someone (like a > > GNU/Linux or BSD distribution would like to see one for their packages) > > in that case. On Tue, May 27, 2008 at 11:49:27PM +0200, Richard Guenther wrote: > I'd rather close the 4.2 branch than the 4.1 one. Unfortunately the FSF > has put us in a situation where we can't do any more 4.1 releases. Can we > slow down the 4.1 snapshot interval to 4 weeks instead? There haven't been any changes since April 8, so in the meantime about six identical snapshots went out. A 4-week interval still would have produced a wasted snapshot. A third alternative is to issue a snapshot (at whatever time interval is chosen) iff there's been a checkin on the branch.
Re: Help with reload and naked constant sum causing ICE
Andy H <[EMAIL PROTECTED]> writes:
> I am am tracking down ICE bug in reload during global register allocation.
>
> I have managed to find root of problem but I am not sure how it should
> work correctly. I would appreciate anyones advise on this.
>
> ICE is from assert in push_reload to ensure that pseudos have been
> replaced with hard register or constants. (reload.c line 940 or so)
> It fails because pseudo equivalent of constant is not (yet) replaced
> for IN.
>
> The sequence of event that causes this to occur is something like this.
>
> 1) Psuedo p68 is marked as equivalent to constant
> reg_equiv_constant[68]=(symbol_ref:HI ("chk_fail_buf") [flags 0x40]
> )
>
> 2) p68+2 is also needed
> (plus:HI (reg/f:HI 68)
> (const_int 2 [0x2]))
>
> 3) find_reloads_address is given p68+2 by find_reloads()
>
> 4) p68+2 is STRICTLY checked as memory address - and target rejects it
> as it has no outer constant and contains psuedo.
> if (strict_memory_address_p (mode, ad))
>
> 5) find_reloads_address then uses LEGITIMIZE_RELOAD_ADDRESS to fix problem
>
> 6) LEGITIMIZE_RELOAD_ADDRESS calls push_reload to reload p68 using
> BASE_POINTER
>
> 7)ICE
> [...]
> Perhaps LEGITIMIZE_RELOAD should fix problem - though that seems odd.
TBH, it sounds like the opposite: LEGITIMIZE_RELOAD_ADDRESS should
not be handling this address at all. If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
If that's legitimate, that's the address you'll get. If it isn't,
the normal reload handling will reload the symbol_ref into a
base register of class:
MODE_CODE_BASE_REG_CLASS (mem_mode, PLUS, CONST_INT)
And it sounds from your message like that's exactly what you want.
Richard
Re: Help with reload and naked constant sum causing ICE
Thank you very much for reply. reload is such a lonely place!
TBH, it sounds like the opposite: LEGITIMIZE_RELOAD_ADDRESS should
not be handling this address at all.
Yes but reload will not do anything before call to L_R_A. So in practice
that would mean L_R_A has
to check reg_equiv_constant[regno] to see if register were a constant
and do nothing if it is.
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
Are you sure? I think it will try
(plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2)))
I could be wrong so I will rerun to check this. If const is missing it
will be rejected as valid address.
Though I note parts of reload do not impose this check.
If that's legitimate, that's the address you'll get. If it isn't,
the normal reload handling will reload the symbol_ref into a
base register of class:
MODE_CODE_BASE_REG_CLASS (mem_mode, PLUS, CONST_INT)
And it sounds from your message like that's exactly what you want.
Not really. - though that might be what happens if cons wrapper is missing.
We can take any relocatable expressions. So first choice is a good one.
Richard
Re: Help with reload and naked constant sum causing ICE
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
This worked just as your described after I added test of
reg_equiv_constant[] inside L_R_A .
So I guess that looks like the fix for bug I posted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
To summarize
LEGITIMIZE_RELOAD_ADDRESS should now always check reg_equiv_constant
before it trying to do any push_reload of register.
Thanks for help!
Re: GCC 4.1 snapshots
On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote: > A third alternative is to issue a snapshot (at whatever time interval > is chosen) iff there's been a checkin on the branch. I thought that's how it worked already.
MIPS stack frame question
Hi.
I'm trying to figure out the structure of MIPS stack frame and how to
write .frame / .mask properly. Since gcc/config/mips/mips.c was
rewritten by Richard Sandiford, it got clearer that what GCC does
(thanks for that).
- In gcc/config/mips/mips.c:mips_compute_frame_info() you do
/* Move above the GPR save area. */
if (frame->num_gp > 0)
{
offset += MIPS_STACK_ALIGN (frame->num_gp * UNITS_PER_WORD);
frame->gp_sp_offset = offset - UNITS_PER_WORD;
}
So what is "- UNITS_PER_WORD" for?
- Why do you put MIPS_STACK_ALIGN in many places? The only constraint
I know is that MIPSpro Assembly Language Programmer's Guide [1] says
"The stack framesize must be a multiple of 16".
- Could you document / comment the reason / source of such
specifications about all of these? :)
Thanks in advance.
Masao
[1]
http://techpubs.sgi.com/library/tpl/cgi-bin/download.cgi?coll=0650&db=bks&docnumber=007-2418-006
Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types
on 27/05/2008 22:00 Andrew Pinski said the following:
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
Thank you for the explanation! I didn't realize the difference.
OTOH, do you think that those arithmetic warnings are practical (as opposed
to being correct)?
I think so as the short int case has a defined overflow of the signed
short type that is SHRT_MAX + 1 is defined while INT_MAX + 1 is not.
I still feel like disagreeing.
Consider this:
*
int main()
{
short short_x;
short_x = short_x + 1;
short_x += 1;
short_x++;
++short_x;
return 0;
}
*
$ gcc43 -Wconversion test-conv2.c -o test-conv
test-conv2.cc: In function 'int main()':
test-conv2.cc:5: warning: conversion to 'short int' from 'int' may alter
its value
test-conv2.cc:6: warning: conversion to 'short int' from 'int' may alter
its value
I thought that in C all 4 forms were equivalent and this was purely a
style choice. Now they are different.
--
Andriy Gapon
