[PATCH] D67656: [llvm-objcopy] Add --set-section-alignment

Alex Brachet via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 23 22:06:03 PDT 2019


abrachet added a comment.

In D67656#1680134 <https://reviews.llvm.org/D67656#1680134>, @MaskRay wrote:

> In D67656#1679119 <https://reviews.llvm.org/D67656#1679119>, @jhenderson wrote:
>
> > I'm very happy to see this change, but I hesitate to diverge in behaviour from GNU's behaviour. I certainly prefer --set-section-alginment to set it to an arbitrary alignment though, so I think we need to lean on the GNU maintainers to change their end.
>
>
> The behavior difference is also my concern, so I hold off on this patch. I argue at https://sourceware.org/bugzilla/show_bug.cgi?id=24942#c9 that --set-section-alignment .foo=8 => sh_addralign=256 is counterintuitive. Please chime in if you feel the same.


When you say chime in do you mean here or on that bug report?

Yes I also think that specifying in powers of two is very strange when no other alignment related flags accept input like this. It seems like from what the people on that bug report said they went for this behavior because bfd represents section alignment in this form. Which is a silly reason to make users need to just remember that this one flag accepts alignment as 2^<align>. In their patch, I wouldn't even get an error `--set-section-alignment .foo=256` would later become `1 << 256` if I followed their code correctly after a quick skim. Now my section has sh_addralign=0 with no warning why, this flag isn't matured yet on their end.

I don't know how long you will need to wait for them to change it given this was committed very recently, and they seemed uninterested in your suggestion to change it to something more sensible.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67656/new/

https://reviews.llvm.org/D67656





More information about the llvm-commits mailing list