On Tue, 2014-06-10 at 21:25 +0200, Aurelien Jarno wrote: > On Tue, Jun 10, 2014 at 08:10:00PM +0200, Mark Wielaard wrote: > > On Mon, 2014-06-09 at 18:02 +0200, Aurelien Jarno wrote: > > > systemtap-sdt-dev was supposed to be something transparent for the > > > glibc, but in practice it causes build failure on at least on alpha (see > > > above). Looking at the BTS, I see it also causes problems with GCC, so I > > > am a bit concerned on other side effects we might haven't seen yet. > > > > Both issues were GCC bugs now fixed on mainline. See > > https://gcc.gnu.org/PR61231 and http://gcc.gnu.org/PR61336. > > The first one was not really related to sys/sdt.h at all. The second was > > indeed a bug in GCC on alpha triggered by the usage of the "i" > > constrained in the sys/sdt.h asm, now fixed. > > I doesn't seems to be the case. PR61336 is about the sys/sdt.h code > triggering an ICE, and it has indeed been fixed. That said it now emits > an error instead of an ICE, so sys/sdt.h is still not usable on alpha, > as the last comment says: > > | Richard Henderson 2014-06-02 16:47:20 UTC > | The ICE has been resolved. > | > | Note that the asm in question comes from system tap, which has not been > | ported to alpha. So you're probably better off disabling that in your > | (e)glibc build too.
I asked Richard and he said that mainline GCC now allows the "i" constraint with a symbol, with an asm. So it shouldn't produce an error. What error are you seeing? stap might not know how to interpret such SDT ELF notes. Since systemtap is not known to work on alpha (I don't know for other SDT consumers like gdb and perf). But that would be independent of building with sys/sdt.h. So unless I misunderstood him things should compile fine, even if you decided to keep sys/sdt.h enabled for the glibc build on alpha. Of course, if none of the SDT consumers are known to work on alpha then having them might just be a noop and it should also be fine to disable them on that platform if you wish. But I don't think that is necessary. > I am therefore re-asking if you can provide a list of architectures > where sys/sdt.h is known to work and doesn't have any issues. As far as I know it builds fine everywhere (modulo any GCC bugs). At least I have personally seen it work fine on x86, x86_64, arm, aarch64, ppc, ppc64 and s390. I have no experience with other arches. But if any arch wouldn't work, then that is a bug that should be fixed of course. Cheers, Mark -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1402429531.3940.67.ca...@bordewijk.wildebeest.org
