Package: fpc Severity: importantNote: this bug report is mostly a reminder to myself, i'm not expecting anyone else to take any action.
In particular this makes it impossible to distinguish for fpc built objects whether they use the soft or hard float ABI and that in turn has been causing some problems with a new glibc version in ubuntu (for now eglibc has been hacked to fix this but we really want fpc to be correctly tagging arm object files (tagging object files on other architectures would be nice too but is less important because they don't have this soft/hard float ABI split)
some (trimmed) irc discussions of this problem with adam conrad are reproduced below
* plugwash wasn't aware it needed fixing<infinity> It does with glibc 2.16... Well, it did before too, we just didn't notice.
<plugwash> what exactly is the problem?<infinity> It's not writing out the eabi extended attributes to its objects, but rather just assuming that linking crti.o will get it everything it needs. <infinity> In 2.15, crti.o (incorrectly) had all the VFP tags turned on, so this worked. In 2.16, it only actually has the tags it needs. <infinity> So, now fpc's armhf binaries are coming out looking suspiciously like armel. <infinity> I'm writing up a local patch to glibc right now, under the assumption that fpc isn't the only compiler that gets this wrong but, ultimately, we need to fix the compiler(s). <plugwash> is this just a cosmetic issue or is it causing problems with the hacks debian/ubuntu made to distinguish armel from armhf in a multiarch context? <infinity> The latter, for sure, but it's also rather incorrect to not have correct eabi tags. <plugwash> Can you file a bug report with details of what tags we should be setting and how to set them in assembler? <infinity> I'll get there, yeah. After I monkeypatch glibc to make sure it'll carry us over for now. <plugwash> file it in debian for now and i'll push it upstream after we've got a patch <infinity> A simple solution for fpc may occur to me when I'm halfway through all of this.
<infinity> In typical shower epiphany style.<plugwash> also in the bug report tell me what version of libc6 I need to use to reproduce the issue (I.E. the version that doesn't have the "monkeypatch" <infinity> Check. If you debootstrap raring right now, that would do for you. <infinity> But I'll give you broken/"fixed" versions for reproduction when I get to filing reports. <infinity> plugwash: Oh, also, glibc and gcc pustream are both carrying the new and improved linker path, so if you (or fpc upstream) are still waffling about pushing that, it's probably safe to assume we're done and decided.
<plugwash> upstream pushed the new linker path without my input :) <infinity> The new one being /lib/ld-linux-armhf.so.3 ? <infinity> If so, yay.<plugwash> yep http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/systems/t_linux.pas?r1=22011&r2=22416 <plugwash> Regarding the tags please file your bug report in debian intitially, i'll push it upstream when I have a patch <infinity> Yup, will do, once I have a handle on what needs changing, and how. <infinity> For now, must shower and go spend time with someone who's far less interested in C libraries than I am.
------------------------------------------------plugwash> BTW last time we spoke it was about elf tagging a new glibc version and the implications for compliers that had not previously been setting tags <infinity> Right. That may have become vaguely moot with some recent changes landed in binutils. I'll have to revisit before I get back to you. <plugwash> what is the current status on that? was eglibc "monkeypatched"? do you have instructions for complier maintainers on what tags need to be set on how to set them? <infinity> Well, not that fpc shouldn't be setting EABI extended attributes (it should be), but it may not be particularly harmful if it fails to do so in the future either. <plugwash> right, do you know where I can find what attributes should be set and how to set them? <infinity> plugwash: I mangled eglibc for now, but there are other bits landing/landed too that make the immediate concern less interesting. <infinity> plugwash: The canonical source for attributes that should be set it the GCC source. I have people yelling at me to come eat some dinner, but I'll give you a pointer to the specific file in the source when I get back and find it again.
<infinity> plugwash: See gcc/config/arm/arm{,-c}.c
<infinity> plugwash: All the calls to EMIT_EABI_ATTRIBUTE
<infinity> plugwash: Which just embeds ".eabi_attribute NN, NN" at the
asm level.
<infinity> plugwash: My short-term dirty hack to glibc was the
following, but it doesn't emit all EABI extended attributes, just enough
to ID a binary as armhf: http://paste.ubuntu.com/1422322/
-- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
