[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 Richard Biener changed: What|Removed |Added Target||i?86-*-* --- Comment #13 from Richard Biener --- Yeah, the C standard only guarantees pointer-to-intptr_t roundtrip for unaltered values. I also think this request is too cumbersome to implement for little benefit.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #12 from Martin Doucha ---
(In reply to Alexander Monakov from comment #7)
> I think your report was misunderstood. Anyway, when EBP is not a frame
> pointer, I think the chances are low that it is derived from ESP. Would
> accurate placement of segment override prefixes be worth the effort compared
> to prefixing all EBP-relative accesses with DS override?
Expanding on my previous comment (#9), EBP should be preferred to address local
arrays and local variables allocated on the stack. Access to these variables
should not have the DS prefix in order to enforce the stack limit. But trying
to trace segment association through function calls that take a pointer and
return another is not worth the effort.
(In reply to Andrew Pinski from comment #10)
> int f(int *a)
> {
> int b;
> size_t t = (size_t)
> size_t t1 = (size_t)a;
> return *(int*)(((size_t))+(t-t1));
> }
>
> Is kinda of valid c but might fail with your definition.
I assume that you're trying to associate the value of pointer "a" with the
stack segment (but that should be ()+(t1-t) instead). As you've writtend it
with the type cast to size_t before adding and subtracting, GCC should just
drop any segment association because you're adding plain numbers, not doing
actual pointer arithmetic. Without the typecast (i.e. ()+(t1-t)), the result
of the pointer arithmetic is undefined according to C standard section 6.5.6
paragraph 8.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #11 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #10)
> int f(int *a)
> {
> int b;
> size_t t = (size_t)
> size_t t1 = (size_t)a;
> return *(int*)(((size_t))+(t-t1));
> }
>
> Is kinda of valid c but might fail with your definition.
The result of integer-to-pointer conversion is implementation-defined, so it's
not necessarily valid if the implementation has segmented memory.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #10 from Andrew Pinski ---
int f(int *a)
{
int b;
size_t t = (size_t)
size_t t1 = (size_t)a;
return *(int*)(((size_t))+(t-t1));
}
Is kinda of valid c but might fail with your definition.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #9 from Martin Doucha --- (In reply to Andrew Pinski from comment #8) > Someone in theory could also use an offset from esp and run into a similar > failure. Well yes, but that would be an actual stack overflow and the whole point is to allow basic protection against that.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #8 from Andrew Pinski --- I didn't misunderstanding it. I just think it is not a valid request. Especially when it comes to it is only this special kvm kernel. Someone in theory could also use an offset from esp and run into a similar failure.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- I think your report was misunderstood. Anyway, when EBP is not a frame pointer, I think the chances are low that it is derived from ESP. Would accurate placement of segment override prefixes be worth the effort compared to prefixing all EBP-relative accesses with DS override?
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #6 from Martin Doucha ---
(In reply to Xi Ruoyao from comment #5)
> No, "Freestanding Environment" has a very specific meaning in the C
> standard. If we must add this it'd be a separate -m{something} argument.
I would say that "execution without any benefit of an operating system" does
have some implication for what you can assume about the stack segment,
therefore properly prefixing EBP dereferences should be controlled by the
parameter.
Just to be clear, I'm not asking for support of arbitrary segment base
addresses, not even for the stack segment alone, because that would require
flawless tracking of segment association for every single pointer. What I'm
asking for is that in a freestanding environment, the stack segment should be
treated as a limited subset of the data segment. All stack addresses must be
accessible through the data segment but some data segment addresses may fall
outside the stack segment limit. This will allow embedded code to set up basic
protection against stack overflow without configuring full page translation.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5 from Xi Ruoyao ---
(In reply to Martin Doucha from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am not so sure this is wanted. GCC assumes a flat memory system for stack
> > and normal memory accesses .
>
> This is certainly not wanted in the most common case where the flat memory
> assumption is correct. But it should be used for compiling embedded binaries
> with -ffreestanding argument.
No, "Freestanding Environment" has a very specific meaning in the C standard.
If we must add this it'd be a separate -m{something} argument.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #4 from Martin Doucha --- (In reply to Andrew Pinski from comment #3) > I think most embedded targets use a flat memory system even on x86_64. I > really think you are barking up the wrong tree on getting this implemented > in GCC (or even LLVM) because of the complexity of tracking the memory. x86_64 targets have no choice about using flat memory because segment limits are ignored by hardware in long mode. This issue is 32bit only. > It is not just about adding ds for ebp accesses. As far as I can tell, EBP and ESP are the only registers that default to stack segment. What else would be needed? > Maybe the easiest fix is to use -fno-omit-frame-pointer to force always the > use of EBP as stack accesses only. That's the first thing I've tried and it didn't help. I had to use -ffixed-ebp as a workaround but that results in a worse performance penalty than prefixes.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #3 from Andrew Pinski --- (In reply to Martin Doucha from comment #2) > > This is certainly not wanted in the most common case where the flat memory > assumption is correct. But it should be used for compiling embedded binaries > with -ffreestanding argument. I think most embedded targets use a flat memory system even on x86_64. I really think you are barking up the wrong tree on getting this implemented in GCC (or even LLVM) because of the complexity of tracking the memory. It is not just about adding ds for ebp accesses. Maybe the easiest fix is to use -fno-omit-frame-pointer to force always the use of EBP as stack accesses only.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 --- Comment #2 from Martin Doucha --- (In reply to Andrew Pinski from comment #1) > I am not so sure this is wanted. GCC assumes a flat memory system for stack > and normal memory accesses . This is certainly not wanted in the most common case where the flat memory assumption is correct. But it should be used for compiling embedded binaries with -ffreestanding argument. > >1) If the address in EBP was calculated from stack pointer value, generate > >unprefixed instructions. > > This fix is not simple really because addresses don't need to be just in EBP > really and even can be stored off into stack memory and then loaded back. > > It seems like there must be a better way of implementing this inside your > kernel as a flat memory system between stack and data segments is not going > to change because it would add a very complex tracking. The worst case for adding prefixes where they're not needed is slight binary size and possibly performance penalty. The worst case for not adding them is stack segment exception. The tracking does not need to be perfect.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-09 Severity|normal |enhancement Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- I am not so sure this is wanted. GCC assumes a flat memory system for stack and normal memory accesses . >1) If the address in EBP was calculated from stack pointer value, generate >unprefixed instructions. This fix is not simple really because addresses don't need to be just in EBP really and even can be stored off into stack memory and then loaded back. It seems like there must be a better way of implementing this inside your kernel as a flat memory system between stack and data segments is not going to change because it would add a very complex tracking.
