- User Since
- Jul 31 2019, 5:45 AM (93 w, 5 d)
Fri, May 14
Thu, May 13
Wed, Apr 28
Apr 16 2021
Removed one duplicated line.
I've updated the patch to fix the test failures, and slightly reworked the driver code to avoid the above iterator invalidation. I've also added a comment there to clarify what it is doing: individually determining whether the sha2 and aes features should be enabled and explicitly setting them, since they can be controlled both by crypto and their specific feature. Using the last occurance of either in the vector ensures whatever options are passed to -mcpu/-march are evaluated in the correct order.
Mar 22 2021
Oct 31 2019
Oct 23 2019
Updated with the new name for the option.
Oct 22 2019
I think -f[no-]force-dwarf-frame suitably describes the behavior, and looks in line with other options. I'll update the patch shortly unless anyone else has any other input.
Oct 17 2019
I added the negative option more as a way to disable the flag, since I'm currently looking at cases where it may want to be turned on by default (and a negative option would then allow you to only get .eh_frame in cases where you'd get both .debug_frame/.eh_frame).
I already spotted the line in CommandFlags.inc needs formatting with a couple of breaks. Also the help text in Options.td could be clearer. In particular, -gno-dwarf-frame shouldn't suggest .debug_frame won't be generated at all (since -g might still emit it). It should probably be more along the lines of:
Oct 11 2019
I've modified the patch so that the new flag will ensure the cfi instructions are actually present to be emitted as well. I went ahead and renamed the flag -gdwarf-frame too, to better reflect that it's dealing with the debug information you'd otherwise get with -g, and is meant to specifically put the information in a .debug_frame section and not .eh_frame.
Sep 6 2019
I was actually torn myself on whether to put the flag in the g group or not, so I'm happy to rename it. As far as I could find, no compiler has an existing option to control this: instead armcc always includes a debug_frame section by default to follow Arm's Dwarf specification. Having it as an option seems more flexible than forcing a different behavior.
Sep 5 2019
Aug 15 2019
Ping. @compnerd any other changes before this could be accepted?
Aug 8 2019
Adjusted the formatting on some comment lines, and added FIXMEs for all the constraints that require additional validation to clarify what is still needed and where.