Am Montag, den 17.12.2018, 10:28 -0700 schrieb Jeff Law: > On 12/16/18 3:45 PM, Uecker, Martin wrote: > > Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law: > > > On 12/16/18 6:45 AM, Uecker, Martin wrote: > > > > Am Freitag, den 14.12.2018, 18:20 -0700 schrieb Martin Sebor: > > > > > On 12/14/18 4:36 PM, Jeff Law wrote: > > > > > > On 12/14/18 3:05 AM, Uecker, Martin wrote: > > > > > > > > > > > > > > Am Donnerstag, den 13.12.2018, 16:35 -0700 schrieb Jeff Law: > > > > > > > > On 12/12/18 11:12 AM, Uecker, Martin wrote: > > > > > > > ...
> > > There's certainly targets where 1 byte function alignment is important > > > from a code space perspective -- it's likely that function descriptors > > > will never be supported on those targets. > > > > But most architectures require a higher alignment anyway. > > Here is a list of all targets where function alignment > > is 1 byte: > > > > gcc/config/avr/avr.h:#define FUNCTION_BOUNDARY 8 > > gcc/config/i386/i386.h:#define FUNCTION_BOUNDARY 8 > > gcc/config/m32c/m32c.h:#define FUNCTION_BOUNDARY 8 > > gcc/config/mn10300/mn10300.h:#define FUNCTION_BOUNDARY 8 > > gcc/config/pa/pa.h:#define FUNCTION_BOUNDARY BITS_PER_WORD > > gcc/config/rl78/rl78.h:#define FUNCTION_BOUNDARY 8 > > gcc/config/rx/rx.h:#define FUNCTION_BOUNDARY ((rx_cpu_type > > == RX100 || > > rx_cpu_type == RX200) ? 4 : 8) (BTW: pa was included here by mistake) > > > > From this list only i386 currently adds the target hook and > > would be affected by this patch. But arm is also affected: > > > > > It's also important to remember that not every target which uses > > > function descriptors uses the LSB. On some targets the LSB may switch > > > between modes (arm vs thumb for example). So on those targets the use > > > of descriptors may imply an even larger minimum alignment. > > > > Yes, arm reserves the lowest 2 bits so since we require an additional > > bit and this increases the minimum alignment from 4 to 8 bytes on > > aarch64. > > > > Here are the architectures which currently support function > > descriptors and the bit used: > > > > $ grep TARGET_CUSTOM gcc/config/*/*.c | grep define > > gcc/config/aarch64/aarch64.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 4 > > gcc/config/arm/arm.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 2 > > gcc/config/csky/csky.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/i386/i386.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/ia64/ia64.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 0 > > gcc/config/mips/mips.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 2 > > gcc/config/or1k/or1k.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/powerpcspe/powerpcspe.c:#define > > TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/riscv/riscv.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/rs6000/rs6000.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/s390/s390.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > gcc/config/sparc/sparc.c:#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > > > For mips minimum alignment is 4 bytes, so here alignment would > > not change. > > > > > Ultimately using function descriptors is an ABI breaking choice and we > > > might declare that function descriptors imply higher function > > > alignments. > > > > Increasing the alignment is not an ABI breaking change. > > Increasing alignment is also an ABI change if you make those low bits > have a new meaning. Absolutely, but this would only happen with the command-line flag. > Existing code won't know if the target address is > actually a function descriptor or just a minimally aligned real function. Let's think practically: There are projects which use nested functions and typically these functions and pointers to these functions are used only internally. The code interfaces with existing code, which usually uses an alignment which is sufficient. On most architectures this is the case, because the minimum alignment is already big enough, and on others because the default alignment (atleast with optimization) is big enough. If one is careful (actually checks that no pointer to a nested function escapes and no pointer to functions with smaller alignment are passed in) then using '-fno-trampolines' is perfectly safe. This would then allow to compile these projects in a way which does not require an executable stack. In my opinion this is a very useful feature. Admittedly, we should add the same warning we also have for other ABI-changing options (e.g. for -freg-struct-return) to the description and also only change the minimum alignment when the flag is given. There would then be no impact without the flag and people who know that it safe could still use it. > It's not terribly important, but the HPPA bits above are wrong. It's > minimum alignment is 4 bytes. The low two bits are used for two > different style function descriptors that already exist on that > platform. We may have lied about this to prevent combine from mucking > with anything that examined or modified the low bits in a function address. It's defined to be BITS_PER_WORD so it be correct. I just shouldn't have included in the list. > > > > But the alignment increase itself on 'i386' and 'aarch64' > > might be unacceptable. In this case, the only safe change > > is to make the higher alignment also depend on > > "-fno-trampolines". Would this be acceptable? > > Unclear at this point. The feature is very useful to me, so if I can do something to get this resolved, let me know. Best, Martin
