2015-11-28 8:47 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:> >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> The System V ABI for x86-64 specify that a "red zone" is an area of 128 >> bytes >> above the current stack frame. This area can be used by a called function >> in >> order to avoid the overhead of modifying the stack pointer. The direct >> effect >> is that interrupt/event/signal handlers must not write to this area. In >> the >> UEFI calling convention, there is no such thing and the event handlers do >> write >> their data just above the current stack frame. >> >> However, gcc generate by default code that uses the red zone. This has to >> be >> disabled explicitely with the option -mno-red-zone. Not doing so lead to >> some >> functions behaving randomly once in a while. >> >> Fixing this revealed that some Makefiles out of the efi/ directory have >> some >> specific options when building for BIOS or for EFI. These Makefiles do >> this by >> testing the EFI_BUILD variable. However, this variable wasn't passed down >> the >> Makefiles making these specific options never used. >> > > The addition of the EFI_BUILD variable inside Makefiles could potentially > affect scripts such as package builders, perhaps even the way the > official (pre)release archives are built(?).This variable is not something you're supposed to see or use when building Syslinux. I kinda have the feeling that according to you, no commit shall ever be made again because it may have an interaction with the user / maintainer. Maybe some users rely on the presence of the bugs. Who knows? The difference between a bug and a feature is pretty subjective after all.> > For further details and explanation, see the commit "The make files have > undergone changes to support both i386 and x86_64 platforms" (2012Jun): > repo.or.cz/syslinux.git/commit/38e58635d3868c23537fc5dce87b152a52df34ad > > Perhaps we should consider how to improve the Makefiles without > potentially breaking backwards compatibility?The way I think the Makefiles could be improved is by rewriting them from scratch in a non-recursive way.> PS: Shouldn't this type of things (as described in the aforementioned > commit from 2012Jun) be included in "./doc/building.txt" and in the > corresponding wiki page?Why should they? Celelibi
> > The addition of the EFI_BUILD variable inside Makefiles could potentially > > affect scripts such as package builders, perhaps even the way the > > official (pre)release archives are built(?). > > This variable is not something you're supposed to see or use when > building Syslinux.Read again the commit I referenced.> > I kinda have the feeling that according to you, no commit shall ever > be made again because it may have an interaction with the user / > maintainer.Your kinda of feeling is wrong.> > Maybe some users rely on the presence of the bugs. Who knows? The > difference between a bug and a feature is pretty subjective after all. >This case is neither a feature nor a bug. Whichever parameters the Syslinux Team state that the make command should accept and/or support, the code should work as intended. Once there is a certain way to do things (i.e. how the code interacts with users or with other code), breaking backward compatibility (even for some good reason) is not just a simple plus; there will be negative consequences. Improving code is a good thing, but it is not a goal by itself. The goal of whichever code should be for the resulting binaries to be usable. When a new code breaks backward compatibility, there should be a very good reason, and clear communication is very desirable in such case. If, for instance, packages fail to be built, the improved code is not usable. I am not even sure this patch actually breaks the prior intended usage of "EFI_BUILD". There are many distros with building scripts based on certain things that have been working in a certain way in the Syslinux code for several years. And there are many distros (some of them, very influential ones) in which Syslinux-related code has no maintainer. Breaking backward compatibility will break some of the resulting binaries. I am hoping all patches will _actually_ help and improve the result. By "result" I don't mean the official binaries in some future release (whenever / if it might happen); that's just one of the many intermediate steps.> > > > For further details and explanation, see the commit "The make files have > > undergone changes to support both i386 and x86_64 platforms" (2012Jun): > > repo.or.cz/syslinux.git/commit/38e58635d3868c23537fc5dce87b152a52df34ad > > > > Perhaps we should consider how to improve the Makefiles without > > potentially breaking backwards compatibility? > > The way I think the Makefiles could be improved is by rewriting them > from scratch in a non-recursive way. >If you think so, please, go ahead. Please try to not break backward compatibility. Alternatively, there might be some other known issues that deserve a higher priority / attention. Anyway, Freedom.> > PS: Shouldn't this type of things (as described in the aforementioned > > commit from 2012Jun) be included in "./doc/building.txt" and in the > > corresponding wiki page? > > Why should they?Because there have been enough questions during the years asking how to build under specific conditions certain specific binary files; e.g. cross-compiling, or building while the working directory is not the root of the source code, or building just a couple of binaries, or... Again, read the commit I referenced in my prior email. I am not against improvements. I hope patches are found helpful, including this one, sooner rather than later.> > > CelelibiLet's see new commits being pushed, known issues being solved, ASAP. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
Patrick Masotta
2015-Nov-30 13:14 UTC
[syslinux] [PATCH 0/2] Do not use the "red zone" on EFI
>>> > The addition of the EFI_BUILD variable inside Makefiles could potentially > affect scripts such as package builders, perhaps even the way the > official (pre)release archives are built(?).<<< I think the -mno-red-zone thing is a good catch, the rest of EFI projects all use it; now I wonder if there might be other similar parameters probably overlooked on EFI builds... The variable "EFI_BUILD" is "already" defined at /makefile by the targets "efi32:" and "efi64:" Celeibi's patch seems to only propagate its value and correctly use -mno-red-zone when needed. At first sight I cannot see this mod breaking anything. I just only wonder if -mno-red-zone is now applied to the "whole" EFI codebase without forgetting anycomponent of the build. Best,Patrick
2015-11-30 14:14 UTC+01:00, Patrick Masotta <masottaus at yahoo.com>:>>>> >> The addition of the EFI_BUILD variable inside Makefiles could potentially >> affect scripts such as package builders, perhaps even the way the >> official (pre)release archives are built(?). > <<< > > I think the -mno-red-zone thing is a good catch, the rest of EFI projects > all use it; > now I wonder if there might be other similar parameters probably overlooked > on EFI builds... > > The variable "EFI_BUILD" is "already" defined at /makefile by the targets > "efi32:" and "efi64:" > Celeibi's patch seems to only propagate its value and correctly use > -mno-red-zone when needed. > At first sight I cannot see this mod breaking anything. > I just only wonder if -mno-red-zone is now applied to the "whole" EFI > codebase without forgetting anycomponent of the build. > > Best,Patrick > > >Your mail in in HTML. :) I checked the whole log. The only lines in the logs of "make efi64" starting with gcc that do not contain -mno-red-zone are: - linking invocations - used to compiles .lo files that produce fancyhello.lnx and keytest.lnx (what are those?) - used to build tools that only run on the compiling host: relocs, prepcore, wrapper (note that relocs is no longer used at all) - used to compile assembly file which obviously control the stack usage. The very same goes for "make efi32". "Make bios" produce no occurrence of -mno-red-zone. Regarding the other flags needed, I'll take those from this link: http://www.rodsbooks.com/efi-programming/hello.html - -fno-stack-protector has the same exceptions as above + the installers (which is the right thing to do). - -fPIC is used instead of -fpic, which is good. However, this option is not always specified for efi32, by looking at mk/embedded.mk, it seems to be on purpose. I wonder about the implications of this. syslinux.efi is however always linked with -pie which should be enough to work. - -fshort-wchar is missing out of the efi/ directory. The only places where wchar_t is used are in the directories lzo and gpxe, same for litteral strings with L prefix. We should probably enable this option all the time given it would have no actual effect currently. - -DEFI_FUNCTION_WRAPPER is still defined in some places but never used at all. It shall be replaced by GNU_EFI_USE_MS_ABI under some conditions. So unless there is an objection I may send a patch for those options although it should be a no-op. Best regards, Celelibi