Re: Bombing U-Boot on ARMv4, any hints?
On Tue, Mar 6, 2012 at 7:55 PM, Linus Walleij wrote: > On Tue, Mar 6, 2012 at 12:01 AM, Michael Hope wrote: > >> Hi Linus. Is this the arm-linux-gnueabi-gcc from the Ubuntu binary >> package? > > It's the binary package from: > https://launchpad.net/linaro-toolchain-binaries/trunk/2012.02/+download/gcc-linaro-arm-linux-gnueabi-2012.02-20120222_linux.tar.bz2 > > I'm using Fedora here so cannot really use the Ubuntu package. > But I suspect it's pretty much the same? Yip, it uses the same configuration. The README covers the details. >> If so then the libgcc is an ARMv7 Thumb-2 VFP binary which >> won't run on an ARMv4. > > Aha! That explains everything. > >> The kernel gets around this by providing its >> own helper routines. > > Yes I noticed those helpers in the past, that explains why > my kernel is still booting fine with the same compiler. > >> Does u-boot do the same? > > Well partly it does, for example it has __div64_32() > in lib/div64.c. But the above code does no explicit calls to > that function or the others, my rough guess could be that > the arithmetic is such that libgcc gets linked implicitly, > but what do I know about GCC ... > >> The CodeSourcery toolchain is surviving as it targets ARMv5 by default >> and includes multilibs for earlier architectures? > > Yes probably. > >> What instructions are at or near 0x07fdecd4 and 07fdeb34? > > The boot monitor on the Integrator (ARMv4 system) cannot > disassemble, but the memory looks like this: > > boot Monitor > d 0x07fdecd4 > Displaying memory at 0x7FDECD4 > 0x07FDECD4: 0xF0C04770 > 0x07FDECD8: 0x42888124 > 0x07FDECDC: 0x8116F240 > 0x07FDECE0: 0xF0004211 > 0x07FDECE4: 0xFAB08117 > 0x07FDECE8: 0xFAB1F380 > 0x07FDECEC: 0xEBA2F281 > 0x07FDECF0: 0xF1C30303 > > boot Monitor > d 0x07fdeb34 > Displaying memory at 0x7FDEB34 > 0x07FDEB34: 0xE1A04000 > 0x07FDEB38: 0xEBCE > 0x07FDEB3C: 0xE0804004 > 0x07FDEB40: 0xEBCC > 0x07FDEB44: 0xE154 > 0x07FDEB48: 0x3AFC > 0x07FDEB4C: 0xE8BD8010 > 0x07FDEB50: 0x000F4240 Hacking this into an assembly file then running objdump over it suggests this is Thumb-2 code. I think that's the problem. Sorry I don't have a solution. We're considering multilib in the future but it's not Linaro's focus. If I were to hack around it I'd grab the libgcc.a from Fedora (v5) or Debian (v4T) and drop it in over the supplied libgcc.a. This may void your warranty :) You could try the R&M baremetal toolchain. We're working with them on the build side: https://launchpad.net/gcc-arm-embedded -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bug triaging of 945503
Hi! I need a little help with triaging of this bug, it is a little different from the ones I have triaged so far: https://bugs.launchpad.net/launchpad/+bug/945503 - gcc-4.7 branch imports fail (timeouts) It is already set to Confirmed, my question is what is needed to go to the triaged stage? Also, the comments from wgrant and jelmer somewhat indicates that there is no problem. Best regards Åsa ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Updates sysroots for binary toolchain
Hi Updated sysroots for binary toolchain are available at [1]. This time I split -dev and -dbg sysroots so as long as dbgsym are not needed less disk space is used. Please take a look at them and report any issues. 1. http://people.linaro.org/~hrw/generic-linux/sysroots/20120301/ ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Test failures due to directory names in the test farm
Hello, since this long-standing problem just hit me again, I had a quick look at test failures in our farm that appear to occur whenever the directory name contains a string that is being checked for via a "scan-assembler" test, e.g.: +FAIL: gcc.target/arm/sat-1.c scan-assembler-times ssat 4 +FAIL: gcc.target/arm/sat-1.c scan-assembler-times usat 4 I had been assuming this happens because the directory name somehow finds its name into the assembler file, e.g. via a .file directive or DWARF data, and therefore an additional instance of the search string is being detected erroneously. However, when I attemted to re-create the scenario by building myself within a directory that has the same name, but on my local machine, the tests when through fine. And indeed, inspecting the assembler source shows that that there is no debug info at all; while there is a .file directive, it contains just the file base name without any directory name; and in fact the directory name does not show up at all within the assembler file. Something must still be different in the runs that take place on the build farm; but I currently do not understand what that might be. Michael, is there a way to interact with the build process on the build farm machines themselves to try and find out what's going on here? 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 Vorsitzende des Aufsichtsrats: Martina Koederitz | 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: Test failures due to directory names in the test farm
On 6 March 2012 16:55, Ulrich Weigand wrote: > > Hello, > > since this long-standing problem just hit me again, I had a quick look at > test failures in our farm that appear to occur whenever the directory name > contains a string that is being checked for via a "scan-assembler" test, > e.g.: > > +FAIL: gcc.target/arm/sat-1.c scan-assembler-times ssat 4 > +FAIL: gcc.target/arm/sat-1.c scan-assembler-times usat 4 > > I had been assuming this happens because the directory name somehow finds > its name into the assembler file, e.g. via a .file directive or DWARF data, > and therefore an additional instance of the search string is being detected > erroneously. > > However, when I attemted to re-create the scenario by building myself > within a directory that has the same name, but on my local machine, the > tests when through fine. And indeed, inspecting the assembler source shows > that that there is no debug info at all; while there is a .file directive, > it contains just the file base name without any directory name; and in fact > the directory name does not show up at all within the assembler file. > > Something must still be different in the runs that take place on the build > farm; but I currently do not understand what that might be. Is it possible that the version string has the name of the branch ? That's the only thing I can think of that could be different and could cause this problem. In this : http://ex.seabright.co.nz/build/gcc-linaro-4.7+bzr114970~uweigand~usatssat-4.7/logs/x86_64-natty-cbuild259-oort1-x86_64r1/gcc-testsuite.txt I see - /scratch/cbuild/slave/slaves/oort1/gcc-linaro-4.7+bzr114970~uweigand~usatssat-4.7/gcc/default/build/gcc/xgcc version 4.7.0 20120214 (experimental) [gcc-linaro/usatssat-4.7 revision 114970] (GCC) Is it the version string rather than the directory name ? Ramana > > Michael, is there a way to interact with the build process on the build > farm machines themselves to try and find out what's going on here? > > > 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 > Vorsitzende des Aufsichtsrats: Martina Koederitz | 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: Test failures due to directory names in the test farm
Ramana Radhakrishnan wrote: > Is it possible that the version string has the name of the branch ? > That's the only thing I can think of that could be different and could > cause this problem. > > In this : > http://ex.seabright.co.nz/build/gcc-linaro-4.7 > +bzr114970~uweigand~usatssat-4.7/logs/x86_64-natty-cbuild259-oort1- > x86_64r1/gcc-testsuite.txt > > I see - > > /scratch/cbuild/slave/slaves/oort1/gcc-linaro-4.7 > +bzr114970~uweigand~usatssat-4.7/gcc/default/build/gcc/xgcc > version 4.7.0 20120214 (experimental) [gcc-linaro/usatssat-4.7 > revision 114970] (GCC) > > Is it the version string rather than the directory name ? Ah, good catch! This would certainly explain it, since the version string appears in the assembler source via the .ident directive the compiler always adds ... I guess one could try to change the testsuite scripts to ignore .ident for scan-assembler purposes. But a much simpler fix seems to be to just not add the branch name to the version string when building the compiler in the first place; since those compilers are just used for testing, it doesn't really seem necessary. Michael, any thoughts on this? 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 Vorsitzende des Aufsichtsrats: Martina Koederitz | 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: Bombing U-Boot on ARMv4, any hints?
On Tue, Mar 6, 2012 at 10:42 AM, Michael Hope wrote: > Hacking this into an assembly file then running objdump over it > suggests this is Thumb-2 code. I think that's the problem. Probably so... > Sorry I don't have a solution. We're considering multilib in the > future but it's not Linaro's focus. If I were to hack around it I'd > grab the libgcc.a from Fedora (v5) or Debian (v4T) and drop it in over > the supplied libgcc.a. This may void your warranty :) Hehe :-) Against all odds, this works! I just took the libgcc.a from my old CodeSourcery 2010q1 toolchain and replaced the libgcc.a in the Linaro compiler with it and now it boots and runs like a charm. This is a pretty insane trick but oh so convenient... Thanks Michael! Yours, Linus Walleij ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Problem running updated compiz branches on ARM
Hi Alexandros, Could you use the linaro-toolchain list for stuff like this please? You're more likely to find somebody who knows the answer that way. I'm pretty sure the problem is not the compiler because, as far as I can see, both architectures' compilers emit ".weak" directives. If there is a problem, I'd say it's in the linker. Your test case gives two different addresses on Lucid x86, and on ARM (so you say, I've not tested it), but the same address twice on Precise. This is a surprising result. *I* would have expected that static values in different dlopen'd libraries would not be unified, but apparently they are ... somtimes. I'm afraid I don't really have any insight here. :( Anyway, regardless of whether one is correct, or not, I'd suggest *not* relying on this behaviour - it's clearly not portable. I say leave it at arm's length in production software for a few years. Andrew On 06/03/12 14:27, Alexandros Frantzis wrote: On Tue, Mar 06, 2012 at 09:51:01AM +0800, Sam Spilsbury wrote: On Mon, Mar 5, 2012 at 11:50 PM, Alexandros Frantzis wrote: Hi all, this is an update on my progress with the updated compiz branches. I have been trying to run our update compiz branches (compiz-*/linaro-gles2-update) on ARM (precise armhf), but I have stumbled onto the same issue Marc reported some days ago. In particular, I get: /usr/bin/compiz (core) - Fatal: Private index value "15CompositeWindow_index_4" already stored in screen. /usr/bin/compiz (core) - Fatal: Private index value "15CompositeScreen_index_4" already stored in screen. and then a segfault when I try to run compiz. Note that I *don't* have this problem when running on x86_64 precise. The issue can be recreated with: $ compiz composite opengl I added some debugging messages to pluginclasshandler.h to get a better feeling of what is going on, and ran on both my desktop and on ARM. This is the output near the point when GLScreen get initialized: ... compiz (core) - Info: get(): mIndex.initiated for "8GLScreen_index_4" : 0 compiz (core) - Info: initializeIndex(): Initializining index value "8GLScreen_index_4" compiz (core) - Info: initializeIndex(): Private index value added for "8GLScreen_index_4" compiz (core) - Info: getInstance(): Get instance for "8GLScreen_index_4" compiz (core) - Info: getInstance(): Spawning new class for "8GLScreen_index_4" compiz (core) - Info: ctor(): mIndex.initiated for "8GLScreen_index_4" : 1 compiz (core) - Info: ctor(): Increasing reference count for "8GLScreen_index_4": 1 --- x86_64 --- compiz (core) - Info: get(): mIndex.initiated for "15CompositeScreen_index_4" : 1 --- armhf --- compiz (core) - Info: get(): mIndex.initiated for "15CompositeScreen_index_4" : 0 compiz (core) - Info: initializeIndex(): Initializining index value "15CompositeScreen_index_4" compiz (core) - Fatal: initializeIndex(): Private index value "15CompositeScreen_index_4" already stored in screen. After the composite plugin loads and mIndex.initiated is set to 1, place a watchpoint on mIndex.initiated (it should be a separate template instantiation for each different class) and check if it changes, or check if we are reading mIndex.initiated from a different address, and if so, check the addresses of this for each constructor and destructor being called. (could be a compiler bug, I've hit these on this part of the code before). - In the armhf case, CompositeScreen is erroneously considered not initialized, and is initialiazed again, therefore messing up the plugin system. I am trying to figure out if this is a manifestation of some kind of memory corruption that doesn't affect us on x86_64 for whatever reason (alignment, integer size etc), or something completely different. Thoughts? Thanks, Alexandros -- Sam Spilsbury Hi all, (I have also added Michael, Andrew and Ulrich from the Linaro toolchain group to the recipients. Hi!) Checking the addresses, as Sam suggested, I found that there are two different PluginClassHandler::mIndex and PluginClassHandler::mIndex objects. After a bit of investigation, objdump gave an explanation: objdump -t /usr/lib/compiz/libcomposite.so | c++filt | grep mIndex -- x86_64 -- 00277a80 u O .bss 0010 PluginClassHandler::mIndex 00277a70 u O .bss 0010 PluginClassHandler::mIndex -- armhf -- 00065648 wO .bss 0010 PluginClassHandler::mIndex 00065658 wO .bss 0010 PluginClassHandler::mIndex And the same kind of output for libopengl.so On x86_64 the symbols are marked 'u': 'unique global', whereas on armhf they are marked 'w': 'weak'. This seems to be causing our troubles. I have produced a small test case for this: http://people.linaro.org/~afrantzis/cpp_unique_global.tar.gz Building and running 'LD_LIBRARY_PATH=. ./main' on x86_64 prints out f1 and f2 with the same address, whereas on armhf the addresses are different (i.e. two different objects). On x86_64
Re: Test failures due to directory names in the test farm
On Wed, Mar 7, 2012 at 8:01 AM, Ulrich Weigand wrote: > Ramana Radhakrishnan wrote: > >> Is it possible that the version string has the name of the branch ? >> That's the only thing I can think of that could be different and could >> cause this problem. >> >> In this : >> http://ex.seabright.co.nz/build/gcc-linaro-4.7 >> +bzr114970~uweigand~usatssat-4.7/logs/x86_64-natty-cbuild259-oort1- >> x86_64r1/gcc-testsuite.txt >> >> I see - >> >> /scratch/cbuild/slave/slaves/oort1/gcc-linaro-4.7 >> +bzr114970~uweigand~usatssat-4.7/gcc/default/build/gcc/xgcc >> version 4.7.0 20120214 (experimental) [gcc-linaro/usatssat-4.7 >> revision 114970] (GCC) >> >> Is it the version string rather than the directory name ? > > Ah, good catch! This would certainly explain it, since the > version string appears in the assembler source via the .ident > directive the compiler always adds ... > > I guess one could try to change the testsuite scripts to ignore > .ident for scan-assembler purposes. But a much simpler fix seems > to be to just not add the branch name to the version string when > building the compiler in the first place; since those compilers > are just used for testing, it doesn't really seem necessary. > > Michael, any thoughts on this? (LP: #913997) I use a modified stamp_branch.sh when exporting the merge request which sets the branch to gcc-linaro/branch-name. I've modified this and fired a test run with 'cmp' in the name which historically fails on x86_64 and i686. Let's see how it goes... -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Updates sysroots for binary toolchain
On Wed, Mar 7, 2012 at 1:08 AM, Marcin Juszkiewicz wrote: > Hi > > Updated sysroots for binary toolchain are available at [1]. This time I > split -dev and -dbg sysroots so as long as dbgsym are not needed less > disk space is used. > > Please take a look at them and report any issues. > > 1. http://people.linaro.org/~hrw/generic-linux/sysroots/20120301/ Zhenqiang, could you have a look at these please? I'll have a poke around in the nano-dev image out of interest. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Bug triaging of 945503
On Wed, Mar 7, 2012 at 12:35 AM, Asa Sandahl wrote: > Hi! > > I need a little help with triaging of this bug, it is a little different > from the ones I have triaged so far: > > https://bugs.launchpad.net/launchpad/+bug/945503 - gcc-4.7 branch imports > fail (timeouts) > > It is already set to Confirmed, my question is what is needed to go to the > triaged stage? > > Also, the comments from wgrant and jelmer somewhat indicates that there is > no problem. Hi Asa. Nothing to do here. It's a problem that affects Linaro GCC instead of being one that we caused. I marked it as affecting us so we could track it. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
GDB for Android Card (was: Re: Cards)
Hello, On Tue, 2012-02-28 at 10:12 +1300, Michael Hope wrote: > Hi Ken, Thiago. Could you try your hand at writing cards for the > OpenEmbedded Core meta-layer and GDB and Android? Here is my initial version: https://wiki.linaro.org/ThiagoBauermann/Sandbox/GDBforAndroid What do you think? -- []'s Thiago Jung Bauermann Linaro Toolchain Working Group ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Problem running updated compiz branches on ARM
(Hit send too soon on my last mail and appear to have removed linaro-toolchain Apologies to those who get duplicates) On Tue, Mar 06, 2012 at 04:00:36PM +, Andrew Stubbs wrote: > Hi Alexandros, > > Could you use the linaro-toolchain list for stuff like this please? > You're more likely to find somebody who knows the answer that way. > > I'm pretty sure the problem is not the compiler because, as far as I > can see, both architectures' compilers emit ".weak" directives. If > there is a problem, I'd say it's in the linker. > > Your test case gives two different addresses on Lucid x86, and on > ARM (so you say, I've not tested it), but the same address twice on > Precise. This is a surprising result. *I* would have expected that > static values in different dlopen'd libraries would not be unified, > but apparently they are ... somtimes. I suspect this is a compiler bug around the handling of STB_GNU_UNIQUE_OBJECT- something I suspect was invented to solve the problem in this space - it should all just work in the GNU/Linux world. The assembler files on x86_64 from the small testcase have .type _ZN1AIiE1aE, @gnu_unique_object while the one in case of ARM doesn't have this. However my suspicion about the problem is around the fact that GCC in it's build process emits .type x, @gnu_unique_object to check whether this feature is supported by the GNU assembler. Historically `@' has been a comment character on ARM . So, the compiler doesn't know that GNU_UNIQUE_OBJECT is supported in the assembler and it all falls apart very quickly after that and therefore doesn't generate such code. ... The quickest workaround IMHO is for a new compiler build that is rebuilt with --enable-gnu-unique-object. Given this feature went into a not very recent version of binutils, I would expect most recent assemblers to support this feature and for this to just work (TM). I would expect this configure option to be turned on for cross-compilers as well. It might also be the fastest way of testing this feature. Thoughts ? I would like another set of eyes on this. I verified this works on an armel box by : (natty)lp-ramana@jenipapo:~/cpp_unique_global$ diff -au f12.s f1.s | less --- f12.s 2012-03-07 00:47:32.0 + +++ f1.s2012-03-06 23:25:54.0 + @@ -130,7 +130,7 @@ .weak _ZN1AIiE1aE .section.bss._ZN1AIiE1aE,"awG",%nobits,_ZN1AIiE1aE,comdat .align 2 - .type _ZN1AIiE1aE, %object + .type _ZN1AIiE1aE, %gnu_unique_object .size _ZN1AIiE1aE, 4 _ZN1AIiE1aE: .space 4 and the same for f2.s, regenerating by hand libf1.so and libf2.so and the output generated is : (natty)lp-ramana@jenipapo:~/cpp_unique_global$ LD_LIBRARY_PATH=. ./main f1 0x40028034 f2 0x40028034 regards, Ramana On 6 March 2012 16:00, Andrew Stubbs wrote: > Hi Alexandros, > > Could you use the linaro-toolchain list for stuff like this please? You're > more likely to find somebody who knows the answer that way. > > I'm pretty sure the problem is not the compiler because, as far as I can > see, both architectures' compilers emit ".weak" directives. If there is a > problem, I'd say it's in the linker. > > Your test case gives two different addresses on Lucid x86, and on ARM (so > you say, I've not tested it), but the same address twice on Precise. This is > a surprising result. *I* would have expected that static values in different > dlopen'd libraries would not be unified, but apparently they are ... > somtimes. > > I'm afraid I don't really have any insight here. :( > > Anyway, regardless of whether one is correct, or not, I'd suggest *not* > relying on this behaviour - it's clearly not portable. I say leave it at > arm's length in production software for a few years. > > Andrew > > On 06/03/12 14:27, Alexandros Frantzis wrote: >> >> On Tue, Mar 06, 2012 at 09:51:01AM +0800, Sam Spilsbury wrote: >>> >>> On Mon, Mar 5, 2012 at 11:50 PM, Alexandros Frantzis >>> wrote: Hi all, this is an update on my progress with the updated compiz branches. I have been trying to run our update compiz branches (compiz-*/linaro-gles2-update) on ARM (precise armhf), but I have stumbled onto the same issue Marc reported some days ago. In particular, I get: /usr/bin/compiz (core) - Fatal: Private index value "15CompositeWindow_index_4" already stored in screen. /usr/bin/compiz (core) - Fatal: Private index value "15CompositeScreen_index_4" already stored in screen. and then a segfault when I try to run compiz. Note that I *don't* have this problem when running on x86_64 precise. The issue can be recreated with: $ compiz composite opengl I added some debugging messages to pluginclasshandler.h to get a better feeling of what is going on, and ran on both my desktop and on ARM. This is the output near the point when GLScreen get initialized: >
Re: Updates sysroots for binary toolchain
On 7 March 2012 05:55, Michael Hope wrote: > On Wed, Mar 7, 2012 at 1:08 AM, Marcin Juszkiewicz > wrote: >> Hi >> >> Updated sysroots for binary toolchain are available at [1]. This time I >> split -dev and -dbg sysroots so as long as dbgsym are not needed less >> disk space is used. >> >> Please take a look at them and report any issues. >> >> 1. http://people.linaro.org/~hrw/generic-linux/sysroots/20120301/ > > Zhenqiang, could you have a look at these please? I'll have a poke > around in the nano-dev image out of interest. > Sure. I will do some tests based on 2012.02 release. -Zhenqiang ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: GDB for Android Card (was: Re: Cards)
On Wed, Mar 7, 2012 at 11:02 AM, Thiago Jung Bauermann wrote: > Hello, > > On Tue, 2012-02-28 at 10:12 +1300, Michael Hope wrote: >> Hi Ken, Thiago. Could you try your hand at writing cards for the >> OpenEmbedded Core meta-layer and GDB and Android? > > Here is my initial version: > > https://wiki.linaro.org/ThiagoBauermann/Sandbox/GDBforAndroid It looks nice and concrete. I'll have a play with the style to match the existing cards as an example. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
