https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #1 from Jan Beulich <jbeulich at suse dot com> --- Is this object file representative of the problem? There's exactly one anomaly I'm observing, which is .rodata.str1.4 having an alignment of 4 but not being 4-byte aligned in the file. That shouldn't happen with said upstream change, but: Where's the .rodata.str1.4 contribution coming from? If I assemble the same file with a plain upstream gnueabi (not gnueabihf) assembler, I see all those strings go into .rodata. Is there perhaps a downstream patch involved, which may need updating such that .rodata.str1.4's file position ends up as intended? Otherwise, assuming the gnueabi vs gnueabihf difference isn't relevant (and presumably the various -m... options passed aren't either), how do I reproduce this effect? All of this said, having looked at modpost from this particular angle, I can't spot how .rodata.str1.4's file position would matter to the tool at all. -- You are receiving this mail because: You are on the CC list for the bug.
