Multiarch paths and toolchain implications
n in particular means it is allowed for them to be hard-coded in toolchain source files, as well as in executable files and libraries built by such a toolchain. * Change GCC back-ends to use the well-known multiarch suffix as OS multilib suffix, depending on target and ABI-changing options. Also include multiarch suffix in ELF interpreter name passed to ld. (Probably need to change ld default directory search paths as well.) * Change the dynamic loader ld.so to optionally append the multiarch suffix (as a constant string pre-determined at ld.so build time) after each directory search path, before further appending capability suffixes. (See above as to open questions about -rpath and LD_LIBRARY_PATH.) * Change package build/install rules to install libraries and ld.so into multiarch library directories (not covered in this document). Change system installation to provide for backward-compatibility fallbacks (e.g. symbolic links to the ELF interpreter). * If capability-optimized ISA/ABI-compatible library variants are desired, they can be build just as today, only under the (same) multiarch suffix. They could be packaged either within a single pacakge, or else using multiple packages (of the same multiarch type). * Enforce platform-independent header files across all packages. (In the alternative, provide for multiarch include paths in GCC.) * Build cross-compiler packages with --with-sysroot=/ I'd appreciate any feedback or comments! Have I missed something? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Andrew Stubbs wrote on 08/02/2010 01:35:01 PM: > On 31/07/10 19:01, Ulrich Weigand wrote: > > I've finally completed a first of draft the write-up of toolchain > > implications of multiarch paths that we discussed in Prague. Sorry it took > > a while, but it got a lot longer than I expected :-/ > > > > I'd appreciate any feedback and comments! > > Thanks Ulrich, that's an excellent document. :) > > You didn't mention anything about the HWCAP stuff, though? I think we > need to capture the discussion we had about "multiarch" == "ABI", and > "multiarch" != "hardware features". The second half of the section "Loading/running an executable" is about thw HWCAP stuff (look for "capability suffix"). In the summary I have this point: * If capability-optimized ISA/ABI-compatible library variants are desired, they can be build just as today, only under the (same) multiarch suffix. They could be packaged either within a single pacakge, or else using multiple packages (of the same multiarch type). If you feel this could be made clearer, I'd appreciate any suggestions :-) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Loïc Minier wrote: > Awesome analysis! Thanks! > So I think you analyzed the upstream toolchain behavior Yes, that's true. > and I think > Debian/Ubuntu toolchains cheat in some areas; for some directories > which would use $(version) we use $(major).$(minor) instead, and we > have a $(version) -> $(major).$(minor) symlink. This doesn't really > relate to the multiarch topic, but it reminds me that we ought to fix > the distro divergences so that it's easier to swap an upstream > toolchain with a Debian/Ubuntu one and vice-versa. Agreed. Not sure what this particular divergence helps ... > > Executables built with the old ELF interpreter will not run on a > > system that *only* provides the multiarch install location. This > > is clearly *not* OK. To provide backwards compatibility, even a > > multiarch-capable system will need to install ELF interpreters > > at the old locations as well, possibly via symlinks. (Note that > > any given system can only be compatible in this way with *one* > > architecture, except for lucky circumstances.) > > I see two ways around this; we could patch the kernel to add a dynamic > prefix before the runtime-linker path depending on the executable > contents (typically depending on the arch), This seems awkward. The ELF interpreter location is encoded as full path, which is not interpreted in any way by the kernel. We'd either have to encode particular filesystem layout knowledge into the kernel here, or else add a prefix at the very beginning (or end?), which doesn't correspond to the scheme suggested for multiarch. If we go down that route, it might be easier to use tricks like bind- mounting the correct ld.so for this architecture at the default location during early startup or something ... However, I'd have thought the whole point of the multiarch scheme was to *avoid* having to play filename remapping tricks, but instead make all filenames explicit. > or more elegantly we could > have a generic loader which checks the architecture of the target ELF > file before calling the arch-specific loader. This loader would be > linked to from all the old locations. Well, but then what architecture would that generic loader be in? In the end, it has to be *something* the kernel understands to load natively. > The reason I'm thinking of patching the kernel is because binfmt_misc > is already out there and allows special behavior when encountering > binary files from other architectures (or any binary pattern really). But binfmt_misc only works because in the end it falls back to the built- in native ELF loader. (You can install arbitrary handlers, but the handlers themselves must in the end be something the kernel already knows how to load.) > > Option C: ld.so searches both the -rpath as is, and also with > > multiarch target string appended. > > This is a risk for cross-builds; the native version might be picked up. > While this doesn't seem much of a risk for cross-compilation to an > entirely different architecture (e.g. x86 to ARM), consider > cross-builds from x86-64 to x86, or from EABI + hard-float to EABI + > soft-float. That's one of the fundamental design questions: do we want to make sure only multiarch libraries for the correct arch can ever be found, or do we rather want to make sure on a default install, libraries that have not yet been converted to multiarch can also be found (even taking the chance that they might turn out be of the wrong architecture / variant) ... > BTW, the CodeSourcery patchset contains a "directory poisoning" feature > which seems quite useful to detect these cases early. Yes, that's during compile time. I understand the reason for this is more to catch bad include paths manually specified in packages. Not sure if during load time the same concerns apply. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Andrew Stubbs wrote:
> It is buried a little deep, but it is there. I guess I'd like to see a
> flow of how a binary loads libraries:
>
> 1. User launches binary.
>
> 2. Kernel selects a suitable execution environment (native/qemu).
>
> 3. Kernel reads .interp and loads the multiarch dynamic linker:
> /lib/${mulitarch}/ld.so.
>
> 4. Dynamic linker uses HWCAP to find the most appropriate libc.so.
I thought that's basically the flow of the "Loading/running an executable"
sections ... I've added sub-section headers to maybe make it a bit
clearer.
> We should post it on the Linaro wiki, probably.
It's now on:
https://wiki.linaro.org/WorkingGroups/ToolChain/MultiarchPaths
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: -fremove-local-statics optimization
Andrew Stubbs wrote: > Some discussion later, they decided it would be better to implement the > optimization using inter-procedural dead store analysis: >http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01602.html I agree that this would be a much nicer way ... > This doesn't seem to have actually been done. Not yet, anyway. Maybe this is something we should be working on then? > So basically we're left with this patch that does something we want, but > not in a way that can go upstream. :( > > The question is, should I merge this to Linaro, or not? Loic and I > agreed to hold off until I'd done a bit more research and/or tried to > upstream it again, but now I think we need to think again. The one concern I have is that the patch introduces a user-visible construct: the -fremove-local-statics command line option. If we add this now, and users add the flag to their Makefiles, and then it goes away later on, users' builds could break. On the other hand, we already have the flag in 4.4 anyway, so that risk is there in either case ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: GCC PRE patch; apply or not?
Andrew Stubbs wrote: > CS has this patch in SG++: > http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html > > This patch improves code size in a useful, target independent way, but > was not committed upstream. It's not clear why. Since the patch does not > belong to CodeSourcery, we can't upstream it ourselves either. Steven asked: "What do you folks think of this patch?" and the only answer was by Richi: "I think it's reasonable." So I'm not sure why it didn't go in. Maybe we should just ping Steven? > Is that patch a suitable candidate for Linaro GCC? > > It is not upstreamable due to copyright issues, but we have a policy > that we can keep such patches, if we wish. What copyright issues? Steven ought to have an assignment in place ... > The principle of not letting Linaro and SG++ diverge too far also > suggests keeping it. > > Any thoughts? If nobody objects soon I shall merge it in. Since there don't appear to be any fundamental objections to inclusion of the patch into mainline, and since the patch doesn't introduce any user-visible feature (like syntax extensions or command line options) that could cause build breaks for users if it were to go away after all, I would say this patch is fine for us ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [gnu-linaro-tools] Re: GCC PRE patch; apply or not?
Daniel Jacobowitz wrote: > On Mon, Aug 02, 2010 at 04:31:16PM +0200, Ulrich Weigand wrote: > > Steven asked: "What do you folks think of this patch?" > > and the only answer was by Richi: "I think it's reasonable." > > > > So I'm not sure why it didn't go in. Maybe we should just ping Steven? > > It's been a while, but I think discussion elsewhere (a bug log maybe?) > indicated that Steven wasn't happy with it. Hmm, right, that's probably: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785 Latest status seems to be that the original patch no longer applies, but Joern did an updated (and somewhat modified) version. This seems to have triggered a more general discussion on how to correctly estimate the effect of adding PHI nodes on code size ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Loïc Minier wrote on 08/02/2010 05:30:05 PM: > > > or more elegantly we could > > > have a generic loader which checks the architecture of the target ELF > > > file before calling the arch-specific loader. This loader would be > > > linked to from all the old locations. > > > > Well, but then what architecture would that generic loader be in? In the > > end, it has to be *something* the kernel understands to load natively. > > Currently with binfmt_misc when the kernel loads a binary it will check > whether it's the native architecture and if it is load the ELF dynamic > linker referenced in the binary; if it matches one of the regexps from > binfmt_misc, such as the binary pattern for ARM ELF binaries, it will > call the binfmt interpreter instead, e.g. qemu-arm, and in this case > qemu-arm will load the ELF runtime linker of the target binary to run > the binary inside the CPU emulation. Well, my point is that *qemu-arm* is itself an ELF binary, and the kernel must already know how to handle that. We can have user-space handlers to load secondary architectures that way -- but we cannot have a user-space handler required to load the *primary* architecture; how would that handler itself get loaded? > So I think this should just work; the kernel will call the native ELF > loader of the current arch for binaries for the current arch, and will > load QEMU which will load and emulate the ELF loader for the emulated > arch in the other cases. Maybe I misunderstood something else about your point then, so let's try and take a step back. Today, the location of the ELF loader is embedded into the executable itself, using a full pathname like /lib/ld.so.1. In a multiarch world, this pathname would violate packaging rules, because there are multiple different per-architecture versions of this file. Thus I assumed the straightforward multiarch solution would be to move this file to multiarch locations like /lib/$(multiarch)/ld.so.1, which would require this new location to be embedded into all binaries. I understood you to propose an alternative solution that would keep the old ELF interpreter name (/lib/ld.so.1) embedded in executables, and keep them working by installing some "common" loader at this location. This caused me to wonder what that "common" loader was supposed to be, given that the kernel (for *any* architecture) would be required to be able to load that loader itself natively ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Loïc Minier wrote: > > I understood you to propose an alternative solution that would keep the > > old ELF interpreter name (/lib/ld.so.1) embedded in executables, and > > keep them working by installing some "common" loader at this location. > > Ah no, I intended us to move to /lib/$(multiarch)/ld.so.1, but for > compatibility with executables from other distros and pre-multiarch > world, we need to provide /lib/ld* loaders. OK, I see. > And since the current > /lib/ld* names clash across architectures, I was proposing to replace > /lib/ld* with a clever wrapper that calls the proper > /lib/$(multiarch)/ld.so.1 depending on the architecture of the ELF file > to load. So now we get back to my original question: what file type would that "clever wrapper" be? The kernel can only load an ELF interpreter that is itself an ELF file of the native architecture, so that wrapper would have to be that. However, this means that we've once again violated multiarch rules ... If we have to install different native versions of the clever wrapper, we might just as well install the original native ELF interpreters -- that's neither better nor worse from a multiarch rules perspective. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [gnu-linaro-tools] Re: GCC PRE patch; apply or not?
Andrew Stubbs wrote on 08/02/2010 06:47:36 PM: > On 02/08/10 16:03, Ulrich Weigand wrote: > > Latest status seems to be that the original patch no longer applies, > > but Joern did an updated (and somewhat modified) version. This seems > > to have triggered a more general discussion on how to correctly > > estimate the effect of adding PHI nodes on code size ... > > Do you mean this one? > > http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00250.html Yes, that's the one. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Matthias Klose wrote on 08/02/2010 06:25:58 PM: > this is no "cheating". It makes the packages robust. Remember that some > frontends are built from different source packages and that a > gnat-4.4 (4.4.4) still needs to be buildable with a gnat-4.4 (4.4.3) > and an already updated gcc-4.4 (4.4.4). So the problem that is you want to support a setup where a "gcc" driver installed from a 4.4.4 build can still call and run a "gnat1" binary installed from a 4.4.3 build? That will most likely work. But it still seems a bit fragile to me; in general, there's no guarantee that if you intermix 4.4.4 and 4.4.3 components in that way, everything actually works (that's why they use different directories in the first place). If you want to have separate packages, a cleaner way would appear to be to make them fully self-contained, e.g. have them each provide their own driver that can be called separately. > Of course linaro could build all frontends from one source, but then the two > following issues have to be addressed: > > - gcj/libjava has to be built in arm mode even if gcc defaults > to thumb mode. > > - build gnat from the linaro sources (this may be a problem with the > bootstrap compiler, didn't investigate yet). These sound like problems that ought to be addessed in any case ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Loïc Minier wrote: > > If we have to install different native versions of the clever wrapper, > > we might just as well install the original native ELF interpreters -- > > that's neither better nor worse from a multiarch rules perspective. > > Hmm right; doesn't give us anything more OK, then we're all in agreement again :-) Now this point is where the suggestion to use something like a bind mount on startup comes in. That way, there would be no violation of the multiarch rules, because /lib/ld.so.1 would not be part of any package, and in fact not even part of any file system on disk, but simply be present in the in-memory mount table. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Wookey wrote on 08/02/2010 10:40:23 PM: > Hope that's not considered rude, Ulrich. (great bit of work capturing > all that good stuff - thank you). No problem, that's fine with me. Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Andrew Stubbs wrote: > I suggest teaching the kernel to rewrite that path when it finds a > non-existent interpreter. Presumably the kernel can "know" what > multiarch corresponds to the traditional ABI for any given ELF flags. The problem with this is that is this brings namespace policy into the kernel, which kernel folks have been very opposed to in the past. And I guess that's for good reason. You probably don't want to have to update your kernel in order to support a new ABI / different dynamic linker / or just some different filesystem layout that some userspace use case comes up with for whatever reason ... If there's kernel support needed, the only way that would be acceptable is if all naming policy involved is actually configured from user space. That's another point that would be satisfied by a bind mount solution ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Matthias Klose wrote on 08/02/2010 09:38:49 PM: > On 02.08.2010 21:12, Ulrich Weigand wrote: > > Matthias Klose wrote on 08/02/2010 06:25:58 PM: > > So the problem that is you want to support a setup where a "gcc" driver > > installed from a 4.4.4 build can still call and run a "gnat1" binary > > installed from a 4.4.3 build? That will most likely work. > > No, gnat (4.4.3) has still to work, if gcc (4.4.4) is already installed. OK, where I said "gcc", the same applies also for "gnat", the Ada compiler driver. The reason for why a 4.4.3 gnat would fail if 4.4.4 gcc is installed is that it wouldn't find things like collect2, libgcc, crt*.o etc. Right? > > But it still seems a bit fragile to me; in general, there's no guarantee > > that if you intermix 4.4.4 and 4.4.3 components in that way, everything > > actually works (that's why they use different directories in the first > > place). > > Then I would need to change this internal path with every source change. I > don't see this as fragile as long as it is ensured that we ship with the > different frontends built from the same patchsets/sources. Note that further > restrictions are made by package dependencies. The issues I'm thinking of are things like: suppose the 4.4.4 middle-end adds code that generates calls to some new libgcc library function, which itself was added with the 4.4.4 libgcc. If you now mix-and-match components so that a compiler built from the 4.4.4 sources and using the new middle-end is used together with a libgcc built from the 4.4.3 sources, things will break. It seems that this does not actually occur in the usage model you describe, since you apparently always update the core (libgcc etc.) *first*. I'm not sure if this is actually guaranteed by the package dependencies though. If it is, then I don't see any real problems with that approach ... > > If you want to have separate packages, a cleaner way would appear to be to > > make them fully self-contained, e.g. have them each provide their own > > driver that can be called separately. > > I don't understand that. I don't have a problem with the driver, butwith the > compiler (gnat1). Having the packages self-contained creates > another problem in > that you get file conflicts for files like collect2, various .o files etc. What I was thinking of is along the lines of having gcc-base-4.4.3 and gcc-base-4.4.4 packages that hold the base files (crt*o, libgcc, collect2 ...), such that you can install *multiple* of the base packages at the same time. This way you could have a gcc-4.4.4 (depending on gcc-base-4.4.4) and a gnat-4.4.3 (depending on gcc-base-4.4.3) all installed at the same time. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Multiarch paths and toolchain implications
Matthias Klose wrote: > On 04.08.2010 16:55, Ulrich Weigand wrote: > > The issues I'm thinking of are things like: suppose the 4.4.4 middle-end > > adds code that generates calls to some new libgcc library function, which > > itself was added with the 4.4.4 libgcc. If you now mix-and-match components > > so that a compiler built from the 4.4.4 sources and using the new middle-end > > is used together with a libgcc built from the 4.4.3 sources, things will > > break. > > libgcc is always built from the sources which get uploaded first. Ah, OK. It seems this should work fine then. > sure, you could have separate packages for subminor versions, and introduce a > new dependency package for the minor version (gcc-4.4-defaults), but > I don't see how this would help within the context of the distribution. Going back, the question I was trying to answer is how to set up packages such that they can use the original upstream directory naming scheme, but still allow the package build sequences that you need. My suggestion was simply about a possible way to achieve that; nothing more. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
GDB features and bugfixes
Hi Michael, here's a list of features and bugfixes that can serve as a basis for Monday's discussion on what we should be working on in GDB in the future. The goal of the list is to fix currently known problems with GDB, including the testsuite, as well as bringing GDB on ARM in line with other platforms by adding required back-end support to enable common GDB features that are already supported elsewhere. It does not yet include anything completely new that we'd develop specifically for ARM. If anybody knows of a feature or bugfix I've missed, please let me know! Features/fixes involving kernel support: - hardware watchpoint support - Neon registers in core files - Interrupted syscall handling - PTRACE_ATTACH disabled ? Features/fixes involving GCC support: - backtrace from abort (missing LR save) - debug info for args in varargs routine GDB features/fixes: - prologue parsing on Thumb-2 - displaced stepping on Thumb - syscall tracing support - improved epilogue detection (fix software watchpoints) - multi-threaded debugging inferior crashes - multi-threaded Thumb/ARM state tracking - signal handler stepping - inferior call fixes - misc. other testsuite regressions gdbserver features/fixes - Neon register support - fast tracepoints Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: GDB features and bugfixes
Peter Maydell wrote: > On 8 August 2010 15:30, Ulrich Weigand wrote: > > here's a list of features and bugfixes that can serve as a basis for > > Monday's discussion on what we should be working on in GDB in the future. > > > If anybody knows of a feature or bugfix I've missed, please let me know! > > How about support for process record/replay and reverse debugging? > http://sourceware.org/gdb/wiki/ProcessRecord says that's currently > only supported on x86. Good point; that's certainly another feature to put on the list. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
GDB 7.2 released
Michael, a quick update to our discussion today: actually, GDB 7.2 has already been released earlier today: http://sourceware.org/ml/gdb-announce/2010/msg3.html Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Branding for Linaro GDB package
Hello Michael, I'm looking into "branding" changes needed for a Linaro GDB release. So far I've made the following changes: - Set default PKGVERSION to "Linaro GDB" instead of "GDB" - Set default BUGURL to "http://bugs.launchpad.net/gdb-linaro/"; instead of "http://www.gnu.org/software/gdb/bugs/"; - Set version number according to Linaro version scheme - Update release script to generate tarballs/directories named "gdb-linaro-$VERSION" instead of "gdb-$VERSION". As a result, the default GDB startup output now reads: GNU gdb (Linaro GDB) 7.2-2010.10-0 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. Do you agree that this is the way we should go? Have I overlooked anything? Unless there are objections, I'm planning to check these changes in later this week. As a related question, the generated files in a standard GDB 7.2 release seem to have been built on a relatively old system (RHEL 4 ?), which is visible through the versions of tools like bison, flex, texinfo, and gettext used to build those files. When building our Linaro GDB release tarballs, should we: - just use the tools as installed on a recent build system (say, Ubuntu Lucid), or - attempt to rebuild the release with the exact same set of tools used for the GDB 7.2 release? The second option has the advantage of reducing the amount of changes, e.g. visible in a full diff of the release tarballs. However, it has the disadvantage that reconstructing those exact set of tools (including Red Hat patches, it seems) is somewhat difficult, and can in addition lead to somewhat outdated results ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Branding for Linaro GDB package
Matthias Klose wrote: > Note that these values are overridden when configuring --with-pkgversion and > --with-bugurl. Yes, of course -- for the Ubuntu build they *should* refer to Ubuntu, instead of Linaro. But those defaults are intended for people who build the Linaro GDB from our source releases ... > But this looks fine (and maybe should be used for the Linaro GCC too). OK, thanks. > for the GCC packages I'm using the versions required by upstream > (autoconf2.64, automake1.11), there even is an autoconf2.64 package > for this purpose in the archives. The binutils and GCC toplevel configuries > are kept in sync, not sure about the gdb one. I wasn't refering to the configury files (which are already present in the bzr/cvs repository and will not be regenerated during packaging), but to files like c-exp.c (generated via bison/flex), the gdb.info files (generated via texinfo) or the gdb.pot files (generated via gettext). These are not even present at all in the repository (users building from the repository need to have all those tools installed), but will get generated when packaging up a release source tarball ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Branding for Linaro GDB package
Michael Hope wrote on 09/21/2010 11:44:14 PM: > > As a related question, the generated files in a standard GDB 7.2 release > > seem to have been built on a relatively old system (RHEL 4 ?), which is > > visible through the versions of tools like bison, flex, texinfo, and > > gettext used to build those files. When building our Linaro GDB release > > tarballs, should we: > > - just use the tools as installed on a recent build system (say, Ubuntu > > Lucid), or > > - attempt to rebuild the release with the exact same set of tools used for > > the GDB 7.2 release? > > We should use the tools that come with Lucid. This does cause a > bigger diff but is easier to reproduce and less of a maintenance > problem. OK, sounds good. We'll need to make sure to test the final released tarball, to verify that there's no problem with those versions of generated files ... > I'm not happy with generated files being checked in, but we have to do > that to be drop-in replacement for the upstream GDB. > > If it's straight forward then I'd like to avoid checking in the > generated files if the change is only due to tool changes. We will > regenerate everything as part of the release process but it would be > nice to keep the branch clean. They'll not be checked into the branch; they'll be generated on the fly and simply become part of the tarballs. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Branding for Linaro GDB package
Andrew Stubbs wrote: > GDB seems fine, except that I'd prefer that it didn't say "2010.10-0" > until we actually spin the release. GCC is currently set to "development > 2010.09-2", even though there probably never will be such a release. > Basically, if somebody takes a snapshot, I'd like the --version string > to be different from the official release. Agreed. I was showing how the output of the release build would look like. In the Bazaar repository, I was planning to set the version string to 7.2-2010.10-0-bzr which is similar to what upstream does, except we use -cvs instead of -bzr, and there's a daily date stamp -- but I don't really think we need that for Linaro. > What does gdbserver say? The same: GNU gdbserver (Linaro GDB) 7.2-2010.10-0 Copyright (C) 2010 Free Software Foundation, Inc. gdbserver is free software, covered by the GNU General Public License. This gdbserver was configured as "i686-pc-linux-gnu" Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro GDB release process
Hello, I've now checked the Linaro branding changes in to the gdb-linaro Bazaar repository. I've created a Wiki page describing the Linaro GDB release process based on that repository: http://wiki.linaro.org/WorkingGroups/ToolChain/GDBReleaseProcess (modeled after Andrew's GCCReleaseProcess page) Review and comments are welcome! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: CS MinGW patches
Andrew Stubbs wrote: > As discussed in the meeting yesterday, CodeSourcery has a few MinGW > patches that I had not merged into Linaro GCC. > > I have now investigated these patches, and I'm fairly happy that most > are not necessary for Linaro. They're mainly about interworking with Cygwin. > > The one exception is this one: >http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01214.html > (and even that is primarily a GDB issue). This was merged into mainline libiberty (GCC & GDB) just a couple of weeks ago. I agree this is clearly not necessary for GCC. I can backport it into Linaro GDB 7.2 if needed ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: CS MinGW patches
Michael Hope wrote on 10/05/2010 09:44:54 PM: > On Wed, Oct 6, 2010 at 5:39 AM, Ulrich Weigand wrote: > > Andrew Stubbs wrote: > >> The one exception is this one: > >> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01214.html > >> (and even that is primarily a GDB issue). > > > > This was merged into mainline libiberty (GCC & GDB) just a couple of > > weeks ago. I agree this is clearly not necessary for GCC. I can > > backport it into Linaro GDB 7.2 if needed ... > > Please do. It's landed upstream, is small, is low risk, and is easier > to back port now than to track by other means. I've checked this in now. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: the linaro toolchain and older arm versions
Matthias Klose wrote: > last time I checked this "multilibs" feature was implemented by building the > toolchain N times. By which magic is the correct library selected? I didn't > find anything in fsf trunk which supports this kind of multilibs builds. No, you don't need to build the toolchain multiple times. The toolchain build process for a target that supports multilibs will automatically build the *target libraries* multiple times. This is controlled by a bunch of MULTILIB_... variables set in the target makefile fragment. For example, when configuring GCC for arm-linux-androideabi, the makefile fragment config/arm/t-linux-androideabi is used and sets: MULTILIB_OPTIONS = march=armv7-a mthumb MULTILIB_DIRNAMES= armv7-a thumb This has two effects: first, during GCC build, two extra sets of libraries are built; one with the flag -march=armv7-a, which is stored in a subdirectory called "armv7-a", and one with the flag -mthumb, which is stored in "thumb". The second effect is at that runtime, when GCC is invoked with the -march=armv7-a or -mthumb flags, the GCC driver will search for target libraries in the respective directories "armv7-a" and "thumb" first, before falling back to the default location. This has been supported by GCC for a long time, but it isn't frequently used on Linux targets (except to support -m32/-m64 style bi-arch compilers). One reason is that the GCC multilib scheme only affects target libraries built as part of the GCC build process itself -- it does not solve the problem of providing multiple version of all the other system libraries. (However, embedded targets already make frequent use of multilibs.) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov 29 - Dec 3
== GDB == * Posted updated implementation of #661253 (Improve backtrace by using ARM exception tables) to gdb-patches, which includes several changes requested by reviewers * Posted updated patch to further improve backtrace (in the absence of debug info) to gdb-patches * Commented on a couple of GDB LP bugs == Miscellaneous == * Started setting up IGEP v2 board Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Dec 6 - Dec 10
== GCC == * Tracked down root cause of GCC mainline bootstrap failure on ARM (PR 46040 - "__DTOR_LIST__ undeclared"). == Miscellaneous == * Set up IGEP v2 board (w/ local disk, network, ...) as native GCC / GDB build environment. * Gave talk on Linaro at the "2010 Linux Community Event" at Siemens Munich (w/ Arnd Bergmann). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Linaro gcc ICE bug
Khem Raj wrote: > The bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 files > against GCC trunk also happens with linaro gcc 4.5 > My guess is that there is a backported patch from trunk into linaro > 4.5 tree thats causing this ICE > > This ICE does not happen on upstream gcc-4.5 branch Thanks for the bug report! > I havent figured out the commit yet. It looks like the regression was introduced by Bernd Schmidt's patch to improve zero-/sign-extensions (PR 42172), which we did indeed backport to Linaro GCC 4.5. (I've updated the PR 46883 bugzilla with more details.) > Should you need a bug in linaro > bug tracker I will be happy to file one Yes, please do so; this makes it easier to track the problem on the Linaro side. Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Dec 13 - Dec 17
== GCC == * Completed first successful bootstrap and regression test run of GCC mainline on my IGEPv2 board. * Worked on implementing fix for #617384 (.debug_line is wrong with -fpic) * Worked on backporting fix for #662324 (Pointer type information lost in 4.5 debuginfo) * Analyzed root cause of PR target/46883 (GCC ICE with error: unrecognizable insn) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Extension elimination pass breaks SPU (Fw: spu gcc-4.5 linaro build failure)
Hello, Matthias noticed the following ICE when attempting to build the SPU compiler from the Linaro GCC 4.5 sources: ../../../../src-spu/libgcc/../gcc/libgcc2.c: In function '__fixunssfdi': ../../../../src-spu/libgcc/../gcc/libgcc2.c:1344:1: internal compiler error: in spu_expand_mov, at config/spu/spu.c:4575 It turns out that this is due to the new "extension elimination" pass that was recently added in Linaro GCC, as port from the CodeSourcery compiler. This patch has also been proposed, but not yet included upstream. The problem is that this patch seems to frequently introduce instructions that *set* a sub-word lowpart subreg of a register. Now such instructions, according to the docs, are probably valid RTL, but since the effect of the instruction onto the highpart of the register is deliberately left unspecified, they tend to be very infrequently used. Probably because of this, there seem to be parts of the compiler that simply don't handle such instructions correctly. This has been already noticed in the case of the RTL loop optimizers (see discussion here http://gcc.gnu.org/ml/gcc/2010-11/msg00552.html). The failure in the SPU back-end is another instance of the same problem. SPU needs special code to handle subregs (since a "lowpart" SImode subreg of a DImode register is not actually valid on the SPU, because SImode values live in bytes 0..3 while DImode values live in bytes 0..7 of the otherwise big-endian 16-byte SPU registers), and this code simply aborts when given an assignment to a sub-word lowpart subreg. Now, I guess there's two ways forward: either the outcome of the ongoing discussions on gcc-patches is that it is in fact not a good idea to generate such sets, and the EE pass is subsequently rewritten to avoid them; or else, if those instructions are considered valid, I'll have to extend the SPU move expander to handle them. Thoughts? Matthias, if you need a quick workaround for now, I guess you could disable the new pass for SPU by adding a line "flag_ee = 0;" to spu_override_options. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Extension elimination pass breaks SPU (Fw: spu gcc-4.5 linaro build failure)
Mark Mitchell wrote: > On 12/20/2010 8:35 AM, Ulrich Weigand wrote: > > Matthias noticed the following ICE when attempting to build the SPU > > compiler from the Linaro GCC 4.5 sources: > > With our Linaro hats on, is this something about which we should be > concerned -- other than in so far as we want to get the patch accepted > upstream? Well, I understand we -as Linaro- would like to see Ubuntu base their compiler on ours, but Ubuntu prefers to use a single source base for the compiler for all their supported platforms, including SPU. If we break some of those other platforms in the Linaro compiler, that just creates extra problems for Ubuntu ... > > Now, I guess there's two ways forward: either the outcome of the ongoing > > discussions on gcc-patches is that it is in fact not a good idea to > > generate such sets, and the EE pass is subsequently rewritten to avoid > > them; or else, if those instructions are considered valid, I'll have to > > extend the SPU move expander to handle them. Thoughts? > > I haven't participated in the upstream discussion -- I'm way behind on > that list :-( :-( -- but I think such sets should be considered valid. OK, I'll have a look at fixing the SPU back-end then. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Extension elimination pass breaks SPU (Fw: spu gcc-4.5 linaro build failure)
Ulrich Weigand/Germany/IBM wrote on 12/20/2010 06:01:21 PM: > Mark Mitchell wrote: > > On 12/20/2010 8:35 AM, Ulrich Weigand wrote: > > > Now, I guess there's two ways forward: either the outcome of the ongoing > > > discussions on gcc-patches is that it is in fact not a good idea to > > > generate such sets, and the EE pass is subsequently rewritten to avoid > > > them; or else, if those instructions are considered valid, I'll have to > > > extend the SPU move expander to handle them. Thoughts? > > > > I haven't participated in the upstream discussion -- I'm way behind on > > that list :-( :-( -- but I think such sets should be considered valid. > > OK, I'll have a look at fixing the SPU back-end then. I've now fixed this problem in the back-end upstream: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01694.html I've also created a back-port to Linaro GCC 4.5 and proposed the branch for merge; you can find the details at: https://bugs.launchpad.net/gcc-linaro/4.5/+bug/693425 Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Dec 20 - Dec 23
== GCC == * Checked in mainline fix for #617384 and submitted backport merge requests (.debug_line is wrong with -fpic) * Submitted backport merge requests for the fix for #662324 (Pointer type information lost in 4.5 debuginfo) * Checked in mainline fix for #693425 and submitted backport merge request (SPU back-end incompatible with extension elimination pass) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jan 17 - Jan 21
== GCC == * Analyzed root cause of #685352 (libplymouth2_0.8.2-2ubuntu6 and later give ragged splash and text rendering), opened mainline bugzilla PR rtl-optimization/47299 * Submitted backport merge request for the #685352 fix * Successfully completed profiled-bootstrap run on ARM * Investigated profiled pyhton package build problems == GDB == * Forward-ported GDB patch to support ARM hardware watchpoints * Determined root cause of #615978 (Failure to software single-step into signal handler), started discussion of proposed fix * Miscellaneous Launchpad bug maintenance Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jan 24 - Jan 28
== GCC == * Determined root cause of #Bug 598462 (corrupted profile info with -O[23] -fprofile-use), identified work-around (using -fprofile-correction), and verified on GCC 4.5 and 4.6 == GDB == * Worked on re-implementation of fix for #615978 (Failure to software single-step into signal handler) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Help with define_insn
Ira Rosen wrote:
> (define_insn "neon_vzip_internal"
> [(set (match_operand:VDQW 0 "s_register_operand" "=w")
>(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
> UNSPEC_VZIP1))
>(set (match_operand:VDQW 2 "s_register_operand" "=w")
> (unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
> UNSPEC_VZIP2))]
> "TARGET_NEON"
> "vzip.\t%0, %2"
> [(set (attr "neon_type")
> (if_then_else (ne (symbol_ref "") (const_int 0))
> (const_string "neon_bp_simple")
> (const_string "neon_bp_3cycle")))]
> )
>
> Is there a way to properly mark the dependence?
I guess you need to make sure the UNSPEC_VZIP forms both explicitly
depend on both input operands. This can be a bit tricky due to
various reload constraints on how matching constraints and/or
match_dup can be used, but I think something along the following
lines should work:
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
(match_operand:VDQW 2 "s_register_operand" "w")]
UNSPEC_VZIP1))
(set (match_operand:VDQW 3 "s_register_operand" "=2")
(unspec:VDQW [(match_dup 1) (match_dup 2)]
UNSPEC_VZIP2))]
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Help with define_insn
Ira Rosen wrote:
> After testing only with the vectorizer testsuite (which contains at
> least 30 tests for strided accesses), I'd appreciate comments on the
> patch before I start full testing (cross testing with qemu doesn't
> work so well for NEON).
I cannot really comment on the ARM semantics, but just from the point
of view of how the .md file looks:
- You define new patterns neon_vzip_interleave etc. instead of using
the existing neon_vzip_internal etc., presumably because the
existing patterns are broken. But because they are actually broken,
they should rather be fixed themselves (and *then* used instead of
duplicated).
- You define a bunch of new UNSPEC_ codes which will actually never show
up in RTL, because the expanders that appear to use them always end in
a DONE statement:
+(define_expand "vec_extract_even"
+ [(set (match_operand:VDQW 0 "register_operand" "")
+(unspec:VDQW [(match_operand:VDQW 1 "register_operand" "")
+ (match_operand:VDQW 2 "register_operand" "")]
+ UNSPEC_EXTEVEN))]
+ "TARGET_NEON"
+{
+ rtx tmp = gen_reg_rtx (mode);
+
+ if (BYTES_BIG_ENDIAN)
+emit_insn (gen_neon_vuzp_extract (tmp, operands[1], operands[2],
+ operands[0]));
+ else
+emit_insn (gen_neon_vuzp_extract (operands[0], operands[1],
+ operands[2], tmp));
+ DONE;
+})
It doesn't seem to make much sense to define UNSPECs here; such expanders
can instead simply use naked match_operands like so:
(define_expand "vec_extract_even"
[(match_operand:VDQW 0 "register_operand" "")
(match_operand:VDQW 1 "register_operand" "")
(match_operand:VDQW 2 "register_operand" "")]
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Help with define_insn
Ramana Radhakrishnan wrote: > On 1 February 2011 14:01, Ulrich Weigand wrote: > > - You define new patterns neon_vzip_interleave etc. instead of using > > the existing neon_vzip_internal etc., presumably because the > > existing patterns are broken. But because they are actually broken, > > they should rather be fixed themselves (and *then* used instead of > > duplicated). > > Are they actually broken ? I'd be worried if that were the case. My > understanding is that the > existing ones are being used for the Neon intrinsics / builtins. Yes, they're broken, for the reason Ira originally points out: "The problem with it is that it doesn't express the fact that the two outputs of vzip depend on both inputs, which causes wrong code generation in CSE: for (a,b)<- vzip (c,d) and (e,f) <- vzip (g,d) CSE decides that b==f, since on RTL level b and f depend only on d." (define_insn "neon_vzip_internal" [(set (match_operand:VDQW 0 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")] UNSPEC_VZIP1)) (set (match_operand:VDQW 2 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")] UNSPEC_VZIP2))] The VZIP unspecs must have *both* input registers as operand, since the output actually depends on both. It may be that in the original use (where the output seems to always be written to memory for some reason?) CSE rarely has an opportunity for perform this transformation, but it's still at least latently broken ... > It would be a good thing to integrate the 2 of them together if at all > possible. I think if the original pattern is fixed, Ira should be able to just use it without problem. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jan 31 - Feb 04
== GDB == * Prepared Linaro GDB 7.2-2011-02.0 release * Committed two patches to implement LP #661253 (Improve backtrace by using ARM exception tables) to mainline and Linaro GDB 7.2 * Provided two follow-on fixes to the patch for LP #616000 (Handle -fstack-protector prologue code); both applied to mainline and Linaro GDB 7.2 * Backported mainline fix for LP #685494 (gdb.xml/tdesc-regs.exp failure) to Linaro GDB 7.2 * Identified root cause of LP #711375 (gdb internal error in inline_frame_this_id trying to debug a qemu target); committed fix to mainline and Linaro GDB 7.2 * Worked on re-implementation of fix for LP #615978 (Failure to software single-step into signal handler) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Problems with kernel support for hardware watchpoints
Hello Will, I've been trying to get GDB support for hardware watchpoints/breakpoints going. I've ported Matthew's GDB patch to current mainline, and am running this under a 2.6.37-1002-linaro-omap kernel on an IGEPv2 board. However, something seems to be not quite working: I'm seeing this kernel message on boot: hw-breakpoint: debug architecture 0x4 unsupported. and then at runtime, the result of a PTRACE_GETHBPREGS call for register 0 is 0x04000106: debug architecture: 4 watchpoint size: 0 nr. watchpoints: 1 nr. breakpoints: 6 This leads me to a couple of questions: - It seems odd that the kernel says it doesn't support the debug architecture, but then reports to user space that 1 watchpoint and 6 breakpoints are supported ... GDB will never use the watchpoint, because the maximum watchpoint size is reported as zero, but GDB will attempt to use the breakpoints. Setting a breakpoint will appear to succeed, but then the breakpoint just never triggers. The kernel should IMO be more consistent in how unsupported configurations are handled ... - Why is architecture 0x4 not supported? This seems to be the variant of the v7 debug architecture with memory-mapped registers. Apparently the IGEP only supports this version ... Do you know what the Beagle-/Pandaboard and other clones do? What would it take to support this architecture variant? Given the widespread use of those boards, it would be really nice if we could support hardware debugging on them ... - Which hardware *is* supported? Can you recommend a board I should be using to verify GDB support is working? Thanks for your help in getting this working! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RE: Problems with kernel support for hardware watchpoints
Hi Will, > > - It seems odd that the kernel says it doesn't support the debug > > architecture, but then reports to user space that 1 watchpoint and 6 > > breakpoints are supported ... GDB will never use the watchpoint, because > > the maximum watchpoint size is reported as zero, but GDB will attempt to > > use the breakpoints. Setting a breakpoint will appear to succeed, but then > > the breakpoint just never triggers. The kernel should IMO be more > > consistent in how unsupported configurations are handled ... > > Agreed. This is an artifact of how the ptrace info register is populated. > I'll work on a fix tomorrow so that we don't report any resources when > the architecture is unsupported. Great, thanks! > > - Why is architecture 0x4 not supported? This seems to be the variant of > > the v7 debug architecture with memory-mapped registers. Apparently the > > IGEP only supports this version ... Do you know what the > > Beagle-/Pandaboard and other clones do? What would it take to support this > > architecture variant? Given the widespread use of those boards, it would > > be really nice if we could support hardware debugging on them ... > > The memory-mapped interface is hugely unreliable in real hardware because > you have to calculate the address of the memory-mapped debug registers by > using a base and offset, which are hardcoded in some information registers. > Unfortunately, I've never found a board where these registers have been > programmed correctly so (a) I had nothing to test my code with (b) few people > would be able to use it and (c) there's not really a safe way to go around > poking random areas of memory. Huh, I see. I have no idea whether those information registers contain correct values on IGEP .. > > - Which hardware *is* supported? Can you recommend a board I should be > > using to verify GDB support is working? > > The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. > The A5 should work (untested) and the A15 will need a bit of hacking to > get it supported. OK. I guess I can try on our Versatile Express. > > Thanks for your help in getting this working! > > No problem. If you find anybody with working memory-mapped debug and some > spare time, I'd be happy to review patches :) Thanks! I'll try and see if I can figure out where the MM area is on the IGEP ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RE: Problems with kernel support for hardware watchpoints
"Will Deacon" wrote on 02/11/2011 10:13:01 AM: > I don't have a pandaboard, so I'd be interested to see if the code > works there. I developed it using ARM boards, so the versatile express > is a known good target. I've now got it working reliably on on Versatile Express, after fixing a couple of bugs on the GDB side (both in the HW-watchpoint patch, and in common GDB code). The testsuite now passes with no regressions when enabling HW watchpoints, except for two tests that require more than one single watchpoint to be supported. This raises another couple of issues/questions, however: - In testing on Versatile Express, I noticed what appears to be SMP related bugs in handling regular software breakpoints: occasionally, software breakpoints simply are not hit and execution continues as if the underlying code had not been changed at all. This symptom completely goes away if GDB and the debugged process are forced to the same CPU using the affinity feature (e.g. with schedtool). My guess, just from seeing those symptoms, would be that when inserting a software breakpoint via ptrace, not all i-caches on all CPUs are reliably flushed ... Any thoughts on this? - As mentioned above, the kernel currently only supports one single watchpoint to be active at a time, even though hardware might support multiple ones. The reason seems to be that when a watchpoint triggers, the kernel cannot figure out which one it was (if there's more than one choice). This is a bit unfortunate, given that GDB will attempt to insert two or more watchpoints in many interesting cases (e.g. a "watch *p" command will insert *two* low-level watchpoints, one at the address of p, and one at the address where p (currently) points to). In addition, for regular (write) watchpoints, GDB does not actually *require* the underlying hardware/kernel to specify which watchpoint was hit; GDB is able to find out by itself by checking whether the values at any of the currently active locations actually changed. (For read/access type watchpoints, GDB does require that underlying support -- but those are much more rarely used anyway.) Do you see any chance of improving upon the current behaviour? - Finally, I noticed when reading kernel code that under some circumstances, the kernel will automatically do a single step to get off a watchpoint that was just hit. However, this does not happen for user-space watchpoints installed via ptrace, right? (Just wanting to confirm; since GDB currently does that single step itself -- we don't want *both* kernel and GDB to issue a single step each ...) I haven't gotten to looking further into other hardware (IGEP, Panda) -- that's next on the list. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jan 07 - Feb 11
== GDB == * Installed 2.6.37 Linaro kernel on IGEP and Versatile Express in order to verify support for HW breakpoints/watchpoints * Tested GDB HW watchpoints patch, fixed several bugs in the patch and core GDB, and got it working reliably on vexpress * Started discussion with Will Deacon (ARM) regarding possible further enhancements to related kernel support Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RE: Problems with kernel support for hardware watchpoints
"Will Deacon" wrote on 02/14/2011 11:30:45 AM:
> > - In testing on Versatile Express, I noticed what appears to be SMP
> > related bugs in handling regular software breakpoints: occasionally,
> > software breakpoints simply are not hit and execution continues as if
> > the underlying code had not been changed at all. This symptom
> > completely goes away if GDB and the debugged process are forced to
> > the same CPU using the affinity feature (e.g. with schedtool).
>
> I've seen this issue in the past but I thought I'd fixed it. What kernel
are
> you using and do you have CONFIG_ARM_ERRATA_720789 enabled?
I'm using the 2.6.37-1002-linaro-vexpress kernel from the Linaro package
of the same name. This does *not* have CONFIG_ARM_ERRATA_720789 enabled
(presumably because the mach-vexpress/Kconfig file does not add it?) ...
> > My guess, just from seeing those symptoms, would be that when
inserting
> > a software breakpoint via ptrace, not all i-caches on all CPUs are
> > reliably flushed ... Any thoughts on this?
>
> There was an I-cache aliasing problem in the kernel coupled with a TLB
> invalidation hardware bug on the versatile express. I fixed these though
> and haven't seen any problems since.
Hmm, a TLB flush problem could also explain the symptom (because the write
of the breakpoint to the text section causes a copy-on-write operation
which
installs a new page ...)
I'll try rebuilding the kernel with the above config option enabled.
> Hmmm, I'll need to have a think about this. What does GDB do if it
receives
> a SIGTRAP with si_addr set to (potentially) complete nonsense? As an
aside,
> Cortex-A15 reports the faulting address for a watchpoint correctly, so we
> will be able to use multiple watchpoints there.
The GDB common core can handle either of the following two indications:
A) The (read/write/access) watchpoint at address XXX triggered.
B) A write watchpoint may have triggered at some address.
In the case of B, GDB will scan all the write breakpoints it is currently
tracking and compare the current value at that address with the last value
it remembers being present there. Any changes GDB sees will cause it to
report the corresponding watchpoint as triggered.
As far as the kernel interface is concerned, the important issue that the
ARM native target in GDB is able to understand what the kernel reports, so
it can in turn report either case A or B to the common core.
This means as long as there is some way for GDB to understand the kernel
is reporting a write watchpoint hit at an unknown address, everything is
fine. This could be done e.g. be reporting a "slot" zero in si_errno to
indicate the slot (and then also the address) triggering the watchpoint
is unknown ...
> > - Finally, I noticed when reading kernel code that under some
> > circumstances, the kernel will automatically do a single step to
> > get off a watchpoint that was just hit. However, this does not
> > happen for user-space watchpoints installed via ptrace, right?
> > (Just wanting to confirm; since GDB currently does that single
> > step itself -- we don't want *both* kernel and GDB to issue a
> > single step each ...)
>
> If the {break,watch}point has been inserted via ptrace, the kernel will
> send a SIGTRAP instead of stepping the instruction.
OK, thanks for the confirmation!
> > I haven't gotten to looking further into other hardware (IGEP,
> > Panda) -- that's next on the list.
>
> Good stuff, keep me posted if you see any further problems!
Sure, will do!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RE: Problems with kernel support for hardware watchpoints
> "Will Deacon" wrote on 02/14/2011 11:30:45 AM: > > > > - In testing on Versatile Express, I noticed what appears to be SMP > > > related bugs in handling regular software breakpoints: occasionally, > > > software breakpoints simply are not hit and execution continues as if > > > the underlying code had not been changed at all. This symptom > > > completely goes away if GDB and the debugged process are forced to > > > the same CPU using the affinity feature (e.g. with schedtool). > > > > I've seen this issue in the past but I thought I'd fixed it. What kernel > > are you using and do you have CONFIG_ARM_ERRATA_720789 enabled? > > I'm using the 2.6.37-1002-linaro-vexpress kernel from the Linaro package > of the same name. This does *not* have CONFIG_ARM_ERRATA_720789 enabled > (presumably because the mach-vexpress/Kconfig file does not add it?) ... I've now built a kernel with CONFIG_ARM_ERRATA_720789 enabled, and the symptoms indeed seem to have disappeared completely ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RE: Problems with kernel support for hardware watchpoints
"Will Deacon" wrote on 02/16/2011 01:07:09 PM:
> > I've now built a kernel with CONFIG_ARM_ERRATA_720789 enabled, and the
> > symptoms indeed seem to have disappeared completely ...
>
> Yup - that's because without it, invalidating a TLB entry for a
particular
> process isn't broadcast correctly, so you can end up using the old
(pre-COW)
> mappings if you're running on a different core.
OK. So I guess the only remaining questions is: if this hardware needs the
errata fix to work properly, shouldn't it be automatically selected by the
kernel configure logic? Note that this appears to happen for certain OMAP
boards, see arch/arm/mach-omap2/Kconfig:
config ARCH_OMAP4
bool "TI OMAP4"
default y
depends on ARCH_OMAP2PLUS
select CPU_V7
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789 <<=
select USB_ARCH_HAS_EHCI
But this does not happen for the vexpress; arch/arm/mach-vexpress/Kconfig
has only:
config ARCH_VEXPRESS_CA9X4
bool "Versatile Express Cortex-A9x4 tile"
select CPU_V7
select ARM_GIC
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Feb 14 - Feb 17
== GDB == * Working with Will Deacon, identified root cause of GDB problems running on Versatile Express in SMP mode, and verified that Errata workaround fixes the problem * Finished testing GDB HW watchpoints patch on vexpress, submitted complete patch set for mainline inclusion * Reviewed Yao's mainline patch to enable displaced stepping in Thumb mode Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [ACTIVITY] Feb 14 - Feb 17
Michael Hope wrote on 02/20/2011 08:18:22 PM: > On Sat, Feb 19, 2011 at 7:55 AM, Ulrich Weigand > > * Finished testing GDB HW watchpoints patch on vexpress, > > submitted complete patch set for mainline inclusion > > Let me know when and how and I'll update the build machines. I've now committed HW watchpoint support to mainline GDB, and backported to Linaro GDB 7.2 (rev. 32992). Before you update the build machines, please make sure that the hardware/kernel on those machines actually support HW watchpoints. The simplest way to find out is to verify that the kernel boot messages include something like: hw-breakpoint: found 6 breakpoint and 1 watchpoint registers. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Feb 21 - Feb 25
== GDB == * Worked with Will Deacon and the Linaro kernel team to make sure HW watchpoint and Versatile Express errata fixes are included in the upcoming Linaro kernel release. * Committed GDB HW watchpoint patches to mainline, and backport to Linaro GDB. This completes work on the HW watchpoint blueprint. * Worked on fixing the GDB part of #620611 (Unable to backtrace out of vector page 0x). Posted (two versions of) mainline patch for discussion. * Worked on kernel patch for #615974 (Interrupted system call handling). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Feb 28 - Mar 04
== GDB == * Committed fix for the GDB part of #620611 (Unable to backtrace out of vector page 0x) to mainline and Linaro GDB 7.2. * Ran into GDB crashes due to memory corruption in tests involving multiple inferiors. Tracked down root cause (using valgrind) to long-standing double free bug in GDB terminal state handling code. Committed fix to mainline and Linaro GDB 7.2. * While using valgrind (see above), ran into problems: * ptrace system call is unsupported on ARM * certain variants of the "SUB from SP" Thumb-2 instruction are not handled by the VEX compiler Fixed both problems locally, and was then able to successfully valgrind GDB on ARM. * Created Linaro GDB 7.2-2011.03-0 release. * Worked on glibc patch to add ARM unwind tables to system call stubs; this will help unwinding in the absence of debug info for libc, and in particular fix #684218 (Failures in gdb.base/call-signal-resume.exp) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Work-item tracking for the "gcc-linaro-tracking" LP project
Hi Michael, Andrew, Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro, gdb-linaro etc.) are now also included in the LP work-item tracking statistics (http://status.linaro.org/linaro-toolchain-wg.html). This didn't happen in the past due to a Launchpad issue that has now been fixed. This seems to be working out nicely, except for one issue: what about the gcc-linaro-tracking project? I have a couple of bugs that are fixed in Linaro GCC, and are also fixed in mainline GCC, but they still show up as an "in-progress" work-item in the status tracker (there are a whole bunch more of those assigned to Andrew as well). The reason for this is the LP records have an associated gcc-linaro-toolchain project entry, and this is set to "Fix Committed", but not "Fix Released" ... probably because GCC 4.6.0 is not yet released? Now, on the one hand it does make sense to include the -tracking project in the work-item statistics, because they *do* reflect important tasks: namely, to make sure that the changes indeed land in the upstream repository. However, having them all show up as "in progress" until the community makes a new GCC release does not seem very helpful: this is not in our control, and our work is in fact done once the patch is committed upstream. Therefore my suggestion: we should immediately mark -tracking bugs as "Fix Released" (not "Fix Committed"), as soon as the corresponding patch is committed upstream (and thus our work on the problem is completed). Thoughts? Does this make sense? Will this mess up any of the other purposes for which we currently use the -tracking project? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Mar 07 - Mar 11
== GDB == * Ongoing work on glibc patch to add ARM unwind tables to system call stubs; ran into design problems that look difficult to fix. * As an alternative, started work on a GDB patch to recognize glibc system call assembler stubs via code-scanning; this should allow alloc unwinding in the absence of debug info for current libc code. * Analyzed bug #728216 (GDB fails to get a valid backtrace while debugging a Webkit SIGSEGV) and resolved as invalid; the fault occurs within JIT-generated code where unwinding is impossible. == Misc == * Made travel arrangements for Linaro Summit in Budapest Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Mar 14 - Mar 18
== GDB == * Ongoing work on glibc patch to add ARM unwind tables to system call stubs (bug #684218). * Implemented initial version of a kernel patch that fixes GDB inferior calls while stopped in a restartable system call (bug #615974); started discussion with kernel folks. * Implemented new version of patch to fix single-stepping over signal handlers (bug #615978) that addresses review comments; posted to mailing list. * Verified Linaro GDB patch set can be applied to Ubuntu package. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Mar 21 - Mar 25
== GDB == * Completed glibc patch to add ARM unwind tables to system call stubs (bug #684218), patch committed upstream and backported to Ubuntu glibc. * Posted kernel patch to fixes GDB inferior calls while stopped in a restartable system call (bug #615974); waiting for review. * Ongoing work to fix single-stepping over signal handlers (bug #615978). * Implemented patch to fix single-stepping across bad ARM/Thumb boundary (bug #667309); posted to mailing list for comments. * Contributed two fixes for valgrind on ARM (to enable running GDB under valgrind); both now accepted mainline. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Mar 28 - Apr 01
== GDB == * Committed patch to fix single-stepping across bad ARM/Thumb boundary (bug #667309) to mainline and Linaro GDB. * Committed patch to fix accessing "fpscr" register to mainline. * Ongoing work to fix single-stepping over signal handlers (bug #615978). Posted yet another updated patch to gdb-patches for comments. * Implemented patch to support NEON registers in core files (bug #615972). * Investigated failure to disable address space randomization (bug #616001). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Apr 04 - Apr 06
== GDB == * Ongoing work to fix single-stepping over signal handlers (bug #615978). * Posted patch to support NEON registers in core files (bug #615972). * Failure to disable address space randomization (bug #616001) is shown to be a kernel problem; created stand-alone test case and opened bug against kernel team. == Schedule == * On vacation 04/07 - 04/15. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Changing how we make changes
Michael Hope wrote on 04/08/2011 04:01:42 AM: > The short story is that now, just like mainline, the developers > themselves do the final commit or merge into bzr. I've volunteered > three of you on a review roster so that someone has the responsibility > for reviewing patches each week. The roster is: > * Ramana week 15, 17, 20, ... starting the 11th of April 2011 > * Richard week 16, 18, 21, ... starting the 18th of April 2011 > * Ulrich week 17, 19, 22, ... starting the 25th of April 2011 Is the overlap in just week 17 deliberate? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Apr 18 - Apr 21
== GDB == * Created Linaro GDB 7.2-2011.04-0 release. * Committed patch to fix accessing "fpscr" register to Linaro GDB. * Failure to disable address space randomization (bug #616001) has been fixed in the kernel; closed the Linaro GDB bug. == GCC == * Ongoing analysis of bug #759409 (Profiled bootstrap fails). Identified two independent problems, one related to a new CodeSourcery feature, and one a mis-optimization of final-stage cc1plus which is also present in FSF GCC 4.5 (PR 43085). Ongoing investigation to track down the root cause of the latter problem. == Schedule == * Public holidays 04/22 - 04/25. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Apr 26 - Apr 29
== GDB == * Committed series of patches to fix bug #615978 (Failure to software single-step into signal handler) to mainline and Linaro GDB. * Drafted blueprint linaro-toolchain-o-cross-debug == GCC == * Split bug #771900 (Linaro GCC 4.5 switch optimization breaks profiled bootstrap) off bug #759409 (Profiled bootstrap fails in GCC 4.5). Tracked down root cause of bug #759409 / PR middle-end/43085, and posted fix to gcc-patches. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] May 2 - May 6
== GDB == * Committed support for NEON registers in core dumps (bug #615972) to Linaro GDB (not yet in mainline). * Investigated root cause of bug #615996 (gdb.cp/templates.exp) and started exploring ways to fix it. == GCC == * Committed fix for bug #759409 (Profiled bootstrap fails in GCC 4.5) to FSF GCC 4.5 branch and Linaro GCC 4.5. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Engineering blueprints for 11.11
Michael Hope wrote: > Hi there. The next two weeks is where we take the technical topics > from the TSC and the discussions had during the summit and turn them > into the concrete engineering blueprints for this cycle. I've created > a page at: > https://wiki.linaro.org/MichaelHope/Sandbox/Blueprints > > listing all of the TRs. Could you please have a look through these, > find any with your name on them, and fill in the wiki page. I've put > more notes on the page itself. Some of the topics may warrant > specifications. > > Let me know if you have questions on what the topics actually mean. In the past cycle, I've been using the feature to attach bugs as work items to a blueprint, and I had been planning to do so again for at least some blueprints this cycle. However, this means that work items are added and disappear as bugs are discovered and possibly resolved as invalid. This seems to conflict with the goal that this cycle, work item numbers should stay stable ... Any thoughts on how we should handle this? Also, some of the feedback from UDS sessions included features that could arguably be considered part of our blueprints, but go beyond what was originally their scope. For example, one user asked for GDB tracepoints to be also supported with native debugging, and one asked for enhancements to cross-debugging the kernel via KGDB. At this point it is not clear whether there is anything we can do about those requirements during this cycle, but I think we should keep track of them to make sure they're not forgotten. I could think of a number of ways to do so: - Add work items to the current blueprints (and postpone them if we cannot in the end implement them) - Do more investigation work first, and then add work items later if appropriate - Don't add them at all to the existing blueprints, but queue up new blueprints (possibly for the next cycle) Thoughts? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Engineering blueprints for 11.11
Peter Maydell wrote on 05/19/2011 12:16:58 PM: > On 19 May 2011 10:43, Ulrich Weigand wrote: > > Also, some of the feedback from UDS sessions included features that > > could arguably be considered part of our blueprints, but go beyond > > what was originally their scope. For example, one user asked for > > GDB tracepoints to be also supported with native debugging, and > > one asked for enhancements to cross-debugging the kernel via KGDB. > > > > At this point it is not clear whether there is anything we can do > > about those requirements during this cycle, but I think we should > > keep track of them to make sure they're not forgotten. > > My feeling is that these should be new blueprints (or proto-blueprints > on a wiki page) since they're really separate features. What I found > last cycle was that I had a few mega-blueprints which just accumulated > new work items across the cycle and then at the end had a number of > things postponed. This time round I'm trying for much more tightly > focused blueprints so it's clearer that some features are finished > and some are not (and that some features are high priority and some > are more wishlist). OK, I guess that makes sense. For now I've left those things in the whiteboard of the existing blueprints, but *not* as work times, just as comments. They could be extracted to new blueprints if that's what we decide to do ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jun 14 - Jun 17
== GDB == * Committed support for NEON registers in core dumps (bug #615972) to mainline GDB and binutils repositories. * Added support to readelf (mainline binutils) to correctly display NEON register core file notes. * Started looking into remote gdb testsuite. == GCC == * Investigated reload failure when building kernel with Linaro GCC 4.5 (discovered by Arnd). * Investigated stray function references due to partial inlining breaking kernel build with Linaro GCC 4.6 (discovered by Arnd). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jun 20 - Jun 24
== GDB == * Completed setup and baseline run for remote gdb testsuite. This involved tracking down and working around a variety of problems including: - issues with the cross-compiler packages - board files and sysroot for the debugger to use - timing problems in the dejagnu harness - multiple problems in the GDB testsuite itself At this point, I'm down to about a dozen extra FAILs and about 2000 tests (out of 16000) tests that are not executed in the remote testsuite for one reason or the other. Next step will be to analyze those and create bug reports. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jun 27 - Jul 1
== GDB == * Analyzed all failures and skipped tests in remote gdb testsuite. Opened bug reports to track problems and missing features: 804387 [remote testsuite] Shared library test problems 804392 [remote testsuite] Rebuilt executables not copied 804396 [remote testsuite] Spurious failures 804400 [remote testsuite] Unnecessarily disabled tests 804401 [remote testsuite] Thread support 804403 [remote testsuite] Support for "attach" tests 804405 [remote testsuite] Core file tests 804406 [remote feature] Generate core files 804407 [remote feature] fork/vfork/exec events 804408 [remote feature] Address space randomization 804409 [remote feature] Checkpoints 804411 [remote feature] "info proc" == GCC == * Reviewed several Linaro GCC merge requests. * Fixed mainline reload bug PR rtl-optimization/49114 Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jul 4 - Jul 8
== GDB == * Posted patch to fix shared library remote test problems (#804387). * Started reviewing Yao's latest Thumb-2 displaced stepping patch. == GCC == * Reviewed and approved Richard's mainline reload patch to fix #803232 (ICE on code that uses vld4q_s16() NEON intrinsic). * Followed up on gcc-patches to address concerns about Julian's unaligned access patch. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jul 11 - Jul 14
== GDB == * Tested GDB 7.2.91 prerelease on ARM; everything looking good. * Created a set of patches to prepare for Linaro GDB 7.3 series; verified release process on top of a current 7.3 snapshot. * Committed three mainline patches to fix shared library remote test problems (#804387). * Reviewed Yao's latest Thumb-2 displaced stepping patch. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jul 18 - Jul 22
== GDB == * Committed mainline patch to fix re-built executable remote test problems (#804392). * Committed two more mainline patches to fix remote test issues. == GCC == * Patch review. * Determined root cause of bug #809768 (ICE in bionic libm). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Jul 25 - Jul 29
== GDB == * Committed second mainline patch to fix re-built executable remote test problems (#804392). * Prepared for rebasing Linaro GDB on top of GDB 7.3 release. == Misc == * Prepared for Linaro Connect. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Aug 1 - Aug 5
== GDB == * Created Linaro GDB 7.3 branch * Ported all remaining feature patches from Linaro GDB 7.2 * Backported mainline patches to fix remote test issues: - Fixed #804387 Shared library test problems - Fixed #804392 Rebuilt executables not copied - Fixed #804396 Spurious failures * Committed mainline patch to fix dlopen test cases for remote testing (#804387). * Committed mainline patches to fix misc. other remote test problems (#804396). == Misc == * Attended Linaro Connect in Cambourne. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Aug 8 - Aug 12
== GDB == * Re-tested Linaro GDB 7.3 on Versatile Express (native & remote testing). * Committed patch to re-enable remote thread test cases (#804401) to mainline and Linaro GDB 7.3. * Reviewed Yao's latest Thumb-2 displaced stepping patch. == GCC == * Patch review week. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro GDB 7.3 2011.08 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.3. Linaro GDB 7.3 2011.08 is the first release in the 7.3 series. Based off the latest GDB 7.3, it includes a number of ARM-focused bug fixes. This release includes all bug fixes from the latest Linaro GDB 7.2 release that were not already included in FSF GDB 7.3. In addition, this release fixes: * LP: #804401 [remote testsuite] Thread support * LP: #804387 [remote testsuite] Shared library test problems * LP: #804392 [remote testsuite] Rebuilt executables not copied * LP: #804396 [remote testsuite] Spurious failures The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.3-2011.08 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Aug 15 - Aug 19
== GDB == * Created and published Linaro GDB 7.3 2011-08 release. * Analyzed --with-sysroot=remote: testsuite failures, and opened bug LP #829595. * Reviewed Yao's latest Thumb-2 displaced stepping patch. == Schedule == * I'll be on vacation 08/23 through 08/31. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: request for gdb testing
Michael Hope wrote: > On Thu, Sep 1, 2011 at 11:06 AM, Nicolas Pitre wrote: > > Hello Ulrich (or anyone else acquainted with gdb), > > > > Could the gdb test suite be run on a kernel with the below patch applied > > please? A confirmation that this patch doesn't regress gdb is required > > before this can move ahead. Quick feedback would be greatly > > appreciated. > > Hi Nicolas. I'm afraid Ulrich is away this week and I'm not really > set up for testing with different kernels. GDB is easy to build and > test - a native configure; make; make check should be fine. Hi Nicolas, actually I'm already back today. I'll be happy to verify that this patch doesn't regress GDB. It'll take me a while to set up building a kernel with the patch, but I should hopefully have results later today or maybe tomorrow ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: try_to_freeze() called with IRQs disabled on ARM
Arnd Bergmann wrote on 08/26/2011 04:44:26 PM: > On Thursday 25 August 2011, Russell King - ARM Linux wrote: > > > > Arnd, can you test this to make sure your gdb test case still works, and > > Mark, can you test this to make sure it fixes your problem please? > > Hi Russell, > > The patch in question was not actually from me but from Ulrich Weigand, > so he's probably the right person to test your patch. > I'm forwarding it in full to Uli for reference. Hi Arnd, hi Russell, sorry for the late reply, I've just returned from vacation today ... I've not yet run the test, but just from reading through the patch it seems that this will at least partially re-introduce the problem my original patch was trying to fix. The situation here is about GDB performing an "inferior function call", e.g. via the GDB "call" command. To do so, GDB will: 0. [ Have gotten control of the target process via some ptrace intercept previously, and then ... ] 1. Save the register state 2. Create a dummy frame on the stack and set up registers (PC, SP, argument registers, ...) as appropriate for a function call 3. Restart via PTRACE_CONTINUE [ ... at this point, the target process runs the function until it returns to a breakpoint instruction and GDB gets control again via another ptrace intercept ... ] 4. Restore the register state saved in [1.] 5. At some later point, continue the target process [at its original location] with PTRACE_CONTINUE The problem now occurs if at point [0.] the target process just happened to be blocked in a restartable system call. For this sequence to then work as expected, two things have to happen: - at point [3.], the kernel must *not* attempt to restart a system call, even though it thinks we're stopped in a restartable system call - at point [5.], the kernel now *must* restart the originally interrupted system call, even though it thinks we're stopped at some breakpoint, and not within a system call My patch achieved both these goals, while it would seem your patch only solves the first issue, not the second one. In fact, since any interaction with ptrace will always cause the TIF_SYS_RESTART flag to be *reset*, and there is no way at all to *set* it, there doesn't appear to be any way for GDB to achive that second goal. [ With my patch, that second goal was implicitly achieved by the fact that at [1.] GDB would save a register state that already corresponds to the way things should be for restarting the system call. When that register set is then restored in [4.], restart just happens automatically without any further kernel intervention. ] One way to fix this might be to make the TIF_SYS_RESTART flag itself visible to ptrace, so the GDB could save/restore it along with the rest of the register set; this would be similar to how that problem is handled on other platforms. However, there doesn't appear to be an obvious place for the flag in the ptrace register set ... Bye, Ulrich ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: try_to_freeze() called with IRQs disabled on ARM
Russell King - ARM Linux wrote on 09/01/2011 04:00:00 PM: > On Thu, Sep 01, 2011 at 03:41:22PM +0200, Ulrich Weigand wrote: > > One way to fix this might be to make the TIF_SYS_RESTART flag > > itself visible to ptrace, so the GDB could save/restore it > > along with the rest of the register set; this would be similar > > to how that problem is handled on other platforms. However, > > there doesn't appear to be an obvious place for the flag in > > the ptrace register set ... > > Thanks for looking at this. > > I don't think we can augment the ptrace register set - that would be a > major API change which would immediately break lots of userspace, > causing user stack overflows and such like. Well, it wouldn't need to go into the default register set (REGSET_GPR), but could be in a new register set. This shouldn't change anything for existing applications, but GDB could probe for support for the new regset and use it if present. > I can't see a way out of this - and given the seriousness of the kernel > side issue (causing kernel warnings), and that your change altered the > strace behaviour (an unintended user-visible change) I think we're going > to have to live with the gdb testcase failing until we can come up with > a better fix for it. The change you suggest, with the addition of making the flag available to the debugger in a new register set, should be fine for GDB. I agree that the race you pointed out in the initial mail to this thread needs to be fixed; an in fact, it seems that this race is also present on s390 ... In discussions with Martin, we were wondering however whether the fix you suggest does actually fully plug the race: Assume the scenario you initally describe, where a first signal is ignored and leads to system call restart. With your latest patch, you call into syscall_restart which sets everything up to restart the call (with interrupts disabled). Then, you go back to user space, with PC pointing to the SVC that is to be restarted. Now assume that some interrupt is pending at this point. At the switch to user space, interrupts will be enabled. Can it now happen that this pending interrupt is recognized *before* the SVC is executed? (Maybe the hardware doesn't allow that on ARM ... it definitely *is* possible on s390, though.) If so, can this not then lead to the exact same race you initially described (the interrupt causing some other task to be scheduled, and then an second signal to be delivered to the task about to restart the SVC)? I guess one way to fix this would be to not actually go back to user space for system call restart at all, but instead just short- cut this in entry.S and simply go right back to the system call entry path. As a side benefit, this could eliminate the need to create a stack frame for the OABI RESTARTBLOCK case ... (This is what we do on s390 b.t.w., where there is a similar issue with the system call number being an immediate argument to the SVC instruction.) > I also wonder what the validity of this behaviour is - there are cases > where you can't do what gdb's trying to do - eg, with a syscall using > a restart block (-ERESTART_RESTARTBLOCK) because the restart information > could be wiped out by a new syscall performed by the function gdb wants > to run. Or when the program receives a signal for it to handle while > running that function. Yes, performing an inferior call during a system call that restarts using RESTARTBLOCK is broken. This is a problem on all architectures, and has been ever since the RESTARTBLOCK mechanism was introduced ... To really fix this case would probably require some way for the debugger to save and restore the restore_block saved state. This is not quite trivial, since it would expose that state to user space, effectively creating a new ABI (and probably requiring sanity checks to ensure a valid state is restored). This probably cannot be fixed by one architecture for itself, but would need support from common kernel code. Bye, Ulrich ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Vectorised copy
Michael Hope wrote:
> int *a;
> int *b;
> int *c;
>
> const int ad[320];
> const int bd[320];
> const int cd[320];
>
> void fill()
> {
> for (int i = 0; i < 320; i++)
> {
> a[i] = ad[i];
> b[i] = bd[i];
> c[i] = cd[i];
> }
> }
[snip]
> Can we always use the second form? What optimisation is preventing it?
Without having looked into this in detail, my guess would be
it depends on whether the compiler is able to prove that the
memory pointed to by a, b, and c is distinct (instead of having
a potential overlap if those are pointers into the same array).
Does it help if you make a, b, and c function arguments to fill,
and mark them restrict?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Sep 1 - Sep 2
== GDB == * Russell King now wants to revert my kernel patch that fixed #615974; discussed alternative options. == GCC == * Patch review week. * Analyzed root cause of ICE when building Linux kernel with mainline GCC (reported by Arnd). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: try_to_freeze() called with IRQs disabled on ARM
Russell King - ARM Linux wrote on 09/02/2011 07:22:59 PM: > On Fri, Sep 02, 2011 at 04:47:35PM +0200, Ulrich Weigand wrote: > > Assume the scenario you initally describe, where a first signal is > > ignored and leads to system call restart. With your latest patch, > > you call into syscall_restart which sets everything up to restart > > the call (with interrupts disabled). > > I don't think SIG_IGN signals even set the TIF work flag, so they > never even cause a call into do_signal(). Therefore, as far as > syscalls go, attempting to send a process (eg) a SIGINT which its > handler is set to SIG_IGN results in the process not even being > notified about the attempt - we won't even wake up while the > syscall is sleeping. I don't see why SIG_IGN signals shouldn't set the TIF work flag; the decision whether to ignore a signal is only made once we've got to get_signal_to_deliver. In any case, whether or not the signal is SIG_IGN doesn't matter for the example at all; I'm simply talking about the case whether the first signal we get leads to system call restart, exactly the same as in the original example you initially described here: http://lists.arm.linux.org.uk/lurker/message/20110823.154329.a3e65f95.en.html > > To really fix this case would probably require some way for the > > debugger to save and restore the restore_block saved state. This > > is not quite trivial, since it would expose that state to user space, > > effectively creating a new ABI (and probably requiring sanity checks > > to ensure a valid state is restored). This probably cannot be fixed > > by one architecture for itself, but would need support from common > > kernel code. > > Such state would have to be crytographically signed or kept entirely > within the kernel, as it would otherwise mean that you could redirect > the kernel PC to anywhere... Agreed, that's why the state would need to be verified (in the case of the function pointer, we probably would not want to export the kernel code address to user space in any case, but identify which of the possible target functions is to be called in some other manner). Bye, Ulrich ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Sep 5 - Sep 9
== GDB == * Worked on hardware watchpoint support for gdbserver. == GCC == * Analyzed root cause of three more ICEs when building Linux kernel with mainline GCC (reported by Arnd): PR target/50305: Inline asm reload failure when building Linux kernel PR middle-end/50307: SSA checking ICE when building Linux kernel PR tree-optimization/50318: ICE optimizing widening multiply-and-accumulate * Implemented proposed fix for PR target/50305 and posted for review. == Misc == * Installed updated FPGA bitfiles on my Versatile Express and verified that network stability issues (LP #673820) are now fixed. * Booked Linaro Connect Q4.11 travel. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro GDB 7.3 2011-09 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.3. Linaro GDB 7.3 2011.09 is the second release in the 7.3 series. Based off the latest GDB 7.3, it includes a number of ARM-focused bug fixes and enhancements. This release contains: * Support for hardware breakpoints and watchpoints in gdbserver The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.3-2011.09 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: eglibc and fun with config.sub
Richard Sandiford wrote: > David Gilbert writes: > > My current patch: > > * adds armv6 and armv7 to config.sub > > * adds arm/eabi/armv7 and arm/eabi/armv6t2 and one assembler > > routine in there. > > * If $machine is just 'arm' then it autodetects from gcc's #defines > > * else if $machine is armv then that's still $machine > > I'm taking you literally here, but I think you want things like > armeb-linux-gnueabi to be treated like arm-linux-gnueabi. > > TBH, I think unconditionally using the autodetect (but setting $machine > rather than $submachine, as you say) would be easier and more consistent > across packages. gcc and eglibc will then agree on the target, whereas > the extra complication in the current scheme is there simply to make > eglibc and gcc disagree in certain cases. But I realise we might not > want to fight that fight. FWIW I'd tend to agree that encoding the architecture level into the target triplet seems to lead to more confusion than that it helps ... We certainly never did that on s390 (or powerpc, for that matter); instead, the way to select an architecture level is to build your system compiler to default to that level, and then build all your system libraries with that compiler; the libraries will detect the desired architecture level from GCC defines. On the other hand, given that arm has already gone down the road of using the target triplet, I guess I can see why it might make sense to continue that. In the end, that's for the platform maintainers to decide ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Sep 12 - Sep 16
== GDB == * Completed hardware watchpoint support for gdbserver. * Tracked down watchpoint resource accounting regression on GDB mainline (not present in 7.3). * Created and published Linaro GDB 7.3-2011.09 release. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Linaro GCC 4.6 and 4.5 2011.09 released
Michael Hope wrote: > The PowerPC build fails while building the SPU variant of libstdc++: > > """checking for the value of EOF... configure: error: computing EOF failed > config.status: executing libtool commands > config.status: executing default-1 commands > make[3]: *** [configure-target-libstdc++-v3] Error 1""" > > Perhaps SPU needs to be disabled or some of the target libraries disabled? This probably fails because of a dependency issue; it looks like the SPU newlib packages are not installed (or not found in the correct place). I don't see why this would be any different for the Linaro build, however. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Sep 19 - Sep 23
== GDB == * Committed hardware watchpoint support for gdbserver to mainline, including two minor changes resulting from review comments; backported those fixes to Linaro GDB as well. * Implemented and tested support for disabling address space randomization in gdbserver; patch posted for review. * Investigated support for cross-platform core file generation. == GCC == * Patch review week. * Posted updated patch for PR 50305. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [ACTIVITY] Sep 19 - Sep 23
Christian Robottom Reis wrote on 09/23/2011 10:00:18 PM: > On Fri, Sep 23, 2011 at 06:51:37PM +0200, Ulrich Weigand wrote: > > * Implemented and tested support for disabling address space > >randomization in gdbserver; patch posted for review. > > I'm not sure this is related, but remember that thread where Russell was > commenting about a regression in try_to_freeze() he was going to work on > fixing? I'm curious -- Where did that end up going? No, this is not related. In any case, the current status of the signal handler issue (what the try_to_freeze mail chain was about) is that Russell said he was going to look into it, but so far nothing has happened (he has neither reverted my original patch as he said he might do; nor has he come up with some new patch). I guess I could give him a ping, but since he didn't revert my patch after all, it didn't seem a priority to me ... [ P.S. Maybe you were also thinking of another kernel bug that *did* affect disabling address space randomization (LP #616001): this bug has been fixed upstream by Nicolas a while ago. ] Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [ACTIVITY] Sep 19 - Sep 23
Christian Robottom Reis wrote: > On Mon, Sep 26, 2011 at 03:59:24PM +0200, Ulrich Weigand wrote: > > I guess I could give him a ping, but since he didn't revert my patch after > > all, it didn't seem a priority to me ... > > Interesting. You could reach out and reping just out of courtesy -- I > don't like unfinished business, though code's always unfinished in a way. Sure. I've now pinged Russell again and will try to follow up ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: try_to_freeze() called with IRQs disabled on ARM
Russell King - ARM Linux wrote: > And yes, we can end up processing the interrupt before the SVC is > executed, which is still a hole. So we need to avoid doing the > restart in userspace - which might actually make things easier. > I'll take a look into that over the weekend. Hi Russell, I was wondering whether is there any news on this? If you do rewrite the signal handler processing, please let me know so I can update GDB accordingly ... Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Sep 26 - Sep 30
== GDB == * Worked on support for cross-platform core file generation. * Followed up on patch to support disabling address space randomization in gdbserver. == GCC == * Followed up on patch for PR 50305. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Oct 04 - Oct 07
== GDB == * Reimplemented patch to disable address space randomization in gdbserver to respect the "set disable-randomization" command, and checked it in to mainline and Linaro GDB 7.3 * Worked on support for cross-platform core file generation. == GCC == * Checked in mainline fix for PR 50305. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: limits-fndefn.c and timeouts
Michael Hope wrote: > Separately, does this show a performance problem with var tracking? > Turning on var tracking leads to a 20 x slow down in this particular > case. I'd agree that is a performance problem; probably some nonlinear behaviour in the var tracking algorithms. B.t.w. I'd say that catching such issues is one of the reasons to have those extreme limits tests in the first place ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro GDB 7.3 2011.10 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.3. Linaro GDB 7.3 2011.10 is the third release in the 7.3 series. Based off the latest GDB 7.3, it includes a number of ARM-focused bug fixes and enhancements. This release contains: * Support for disabling address space randomization in gdbserver * Fix for GDB crashes on 3.x kernels * Fix spurious "CRC mismatch" warnings when using "remote:" sysroot The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.3-2011.10 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Oct 10 - Oct 14
== GDB == * Created and published Linaro GDB 7.3-2011.10 release. * Fixed LP #871901 (Linaro GDB crashes on 3.x kernels) in mainline and Linaro GDB 7.3. * Backported mainline fix for LP #829595 (Separate debuginfo misidentified with "remote:" access) to Linaro GDB 7.3. * Completed blueprint "GDB as a cross-debugger". * Worked on support for cross-platform core file generation. == GCC == * Patch review week. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Oct 17 - Oct 21
== GDB == * Worked on support for cross-platform core file generation. Posted initial set of patches for comments. * Created "Toolchain support for kernel debugging" blueprint. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: FW: contribution Linux Kernel Debugger
Michael Hope wrote: > On Thu, Nov 3, 2011 at 10:20 PM, Marc TITINGER wrote: > > Hi there, > > > > As discussed with Loďc, please find attached my slides to the ELCE > presentation related to our implementation of linux-awareness for > JTAG debugging. I still need a formal clearance of my organization > on my contribution patch, but I (and my managers) will be happy to > see some or all of this work benefit to-and-from the community. If > you are interested, I will try to upload a self-contained qemu-based > demo to a public ftp. > > Hi Marc. That would be great. Let me know if we can help with the > upstreaming, Hi Marc. Let me echo Michael's sentiment here: both with my Linaro hat and my GDB global maintainer hat on, I'd really like to see features along the lines you mentioned merged into mainline GDB. If there's anything I can to do help with this process, I'd be happy to do so. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov 8 - Nov 11
== GDB == * Worked on support for cross-platform core file generation. After some discussion on the mailing list it seems we've come to an agreement that the remote protocol ought to have two separate packets related to memory layout, one that describes the permanent, system-wide layout (for embedded systems) and one that describes the dynamic, per-process layout (for processes with memory-mapped files). The latter also ought to be integrated with the "info proc mappings" command, which should work with gdbserver too. I've been working on updating the patches accordingly. == GCC == * Patch review week. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov 14 - Nov 18
== GDB == * Ongoing work on support for cross-platform core file generation. == GCC == * Investigated Launchpad bugs: #889984 binaries: should step across helper functions #889985 binaries: can't step out of helper functions #890764 4.6-11.11 seems to misdetect some files as system header and implicit extern "C" == Misc == * Gave talk on Linaro at the IBM Germany Technical Expert Council fall meeting. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov 22 - Nov 25
== GDB == * Ongoing work on support for cross-platform core file generation. Posted a new design proposal to the mailing list to include not only "info proc mappings", but *all* "info proc" commands. This would involve a remote protocol command to read arbitrary proc files, instead of a specific command to retrieve the memory map. * Investigated Launchpad bug: #891970 msp430-gdb segmentation fault with target remote == GCC == * Patch review week. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
