linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Dave Martin

Hi all, There are various PPAs relevant to linaro, but they can be hard to find when you don't work with them actively. Do we have a list somewhere? If not, it could be worth listing them on the wiki somewhere, or documenting how to find them. Cheers ---Dave

14 years, 4 months

[PATCH 0/2] perf: symbol offset breakage with separated debug

by Dave Martin

Hi all, I've hit some problems in trying to get perf record/report to work correctly on systems with separated debug images (Ubuntu, in particular). I worked on some patches to ensure that separate debug images do actually get loaded, when present -- these commits have now been merged in linux-2.6-tip/master. (See below for a list of the commits.) Now that these are in place, I'm observing a new problem which can mess up symbol locations -- though I think there might be a practical workaround, I can't see a trivial solution, so I'm keen to hear if anyone has any ideas. The problem: perf makes some incorrect assumptions, which mean that the symbol locations seen by perf report and friends can be incorrect. My analysis: a) perf represents symbols as offsets from the start of the mmap'd code region which contains each symbol. b) For shared libs (ET_DYN objects), the desired offset is (usually) equal to the VMA of each given symbol in the image. Perf assumes that these offsets are always equal, and this normally works. Atypical link configurations could cause this to fail, but this would probably be unusual in the real world. c) For executables (ET_EXEC objects), the desired offset is: st_addr - (mmap_start + sh_offset - mmap_offset) Where st_addr is the symbol VMA, sh_offset is the offset of the parent *section* (not segment) from the start of the image, mmap_start is the base VMA of the corresponding mmap'd *segment* (or part of a segment) in memory, and mmap_offset is the file offset at which the mapping starts (as in mmap(2)) (As a minor note, the pgoff field in the perf mmap event data (from which mmap_offset should be deducible) is probably also incorrect at present -- see snippet from util/event.c below.) d) perf assumes that the above is equivalent to: st_addr - (sh_addr - sh_offset) Where sh_addr is the VMA of the start of the symbol's parent section. This is true only given certain assumptions, namely that each symbol's parent section is mapped in such a way that mmap_offset is zero. In practice, this is true for the main executable segment of ET_EXEC images in typical link configurations (i.e., using the default GNU ld scripts). e) The assumptions in (d) break down when using separated debug images, because although separated debug images contain faithful VMA information, the image is stripped of loadable sections' contents, resulting in radically different sh_offset values from the "real" image. Because sh_offset bears no relationship to the layout of the data mmap'd at runtime, this produces bogus symbol adjustments which results in the wrong symbol offsets (a) being calculated. Solutions: (e) needs to be solved in order for perf report etc. to produce sensible output when using separated debug images. I think that a comprehensive solution should also fix the assumptions in (b) and (d) so that any valid ELF images will be processed correctly. Solving (e) doesn't appear trivial, since it requires section layout information from the image that was mmap'd at _runtime_ to be correlated with the symbol information collected maybe from other files at _report_ time. Currently, runtime and report time are treated rather separately, so this isn't straightforward to achieve. A simple workaround in the meantime would be to assume that .text is mmap'd with mmap_offset=0 for ET_EXEC images, and fix the adjustment calculation appropriately. This is not a full fix but is probably worth doing if (as I guess) it gets the tools working correctly in the common case: see [PATCH 2/2] perf symbols: work around incorrect ET_EXEC symbol adjustment ------------------------------------------------------------------------------- My current list of patches in linux-2.6-tip/master: commit 6da80ce8c43ddda153208cbb46b75290cf566fac perf symbols: Improve debug image search when loading symbols commit 8b1389ef93b36621c6acdeb623bd85aee3c405c9 perf tools: remove extra build-id check factored into dso__load commit 21916c380d93ab59d6d07ee198fb31c8f1338e26 perf tools: Factor out buildid reading and make it implicit in dso__load commit 88ca895dd4e0e64ebd942adb7925fa60ca5b2a98 perf tools: Remove unneeded code for tracking the cwd in perf sessions commit 361d13462585474267a0c41e956f1a1c19a93f17 perf report: Don't abbreviate file paths relative to the cwd Illustrative code snippets (from v2.6.35): util/symbol.c: 968:static int dso__load_sym(struct dso *self, struct map *map, const char *name, 969: int fd, symbol_filter_t filter, int kmodule, 970: int want_symtab) 971:{ [...] 1055: elf_symtab__for_each_symbol(syms, nr_syms, idx, sym) { 1133: if (curr_dso->adjust_symbols) { [...] 1134: pr_debug4("%s: adjusting symbol: st_value: %#Lx " 1135: "sh_addr: %#Lx sh_offset: %#Lx\n", __func__, 1136: (u64)sym.st_value, (u64)shdr.sh_addr, 1137: (u64)shdr.sh_offset); 1138: sym.st_value -= shdr.sh_addr - shdr.sh_offset; 1139: } Probable incorrect symbol adjustment which currently gets used for ET_EXEC images. Explanation above. util/event.c: 109:static int event__synthesize_mmap_events(pid_t pid, pid_t tgid, 110: event__handler_t process, 111: struct perf_session *session) 112:{ [...] 153: if (*pbf == 'x') { /* vm_exec */ [...] 166: /* pgoff is in bytes, not pages */ 167: if (n >= 0) 168: ev.mmap.pgoff = vm_pgoff << getpagesize(); 169: else 170: ev.mmap.pgoff = 0; Unless I've misunderstood, getpagesize(2) returns the size in bytes of a page; in this case using it as a shift count is wrong. Also, the code appears to be trying to convert a page count into an address for storage in the profile data. This would mean that when interpreting the data, knowledge of the page size is not needed. However, since I can't see any code which actually uses the pgoff information from the profile data, I'm not sure whether this was the intention. In any case, the offset field from /proc/*/maps is already a byte count, not a page offset, so it does not look necessary to do convert it at all. See [PATCH 1/2] perf events: Fix mmap offset determination. Dave Martin (2): perf events: Fix mmap offset determination perf symbols: work around incorrect ET_EXEC symbol adjustment tools/perf/util/event.c | 8 +------- tools/perf/util/symbol.c | 10 +++++++++- 2 files changed, 10 insertions(+), 8 deletions(-)

14 years, 4 months

New linux-linaro branch and a linux-linaro-meta branch

by John Rigby

Hi Tim, I did a new linux-linaro release yesterday. It is based on the Nico's latest merge and the latest Ubuntu kernel. It is in the master branch here: git://git.linaro.org/jcrigby/linux-linaro.git I have also done a linux-linaro meta package. It is in the master branch here: git://git.linaro.org/jcrigby/linux-linaro-meta.git Thanks John

14 years, 4 months

Linaro Infrastructure Team Weekly Report (2010-08-05 to 2010-08-12)

by Scott Bambrough

The weekly report for the Linaro Infrastructure team may be found at: Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-08-12 Burndown chart: http://people.canonical.com/~pitti/workitems/maverick/arm-infrastructure.ht… Progress: * LEP/DerivativeDistributions: Backend work under way. User testing of UI mockups complete. Feedback being incorporated into mockups for a second round of user testing. * arm-m-private-archive-hosting-infrastructure: Changes to allow LP archive UI to be reskinned should land soon. Some existing bugs fixed to allow easier testing of vostock. Several blueprint items in review and waiting to land. Launchpad monthly release freeze delaying reviews and landing slightly. * arm-m-derived-archive-rebuild: Working together with LP team to consider how to consolidate Linaro/LP changes. Working on archive deletion. Analysis and planning complete, work about to begin on actual coding. Groundwork necessary is not as complete as first thought. Archive deletion is estimated to take longer than originally thought * arm-m-image-building-tool: Blueprint has one remaining work item, met with Cody, Ian about it. Will look into documentation changes Cody proposed. * arm-m-image-building-console: Progress made on getting several bugs fixes landed. Two of the three branches should make it into next LexBuilder release for dogfooding by OEM. Continuing work on other bugs. First security review complete, no surprises. Started process of choosing a new name for release. * arm-m-automated-testing-framework: Reworking authentication code. Pushed a branch for doing browser startup time benchmarking. Added software and hardware profile gathering code. Evaluating OpenPosix and Phoronix test suites on ARM for correctness. Awaiting Linaro board approval for license. * arm-m-validation-dashboard: JSON schema for dashboard data bundle published. Changes from sprint still being reviewed. Should be landed next week. Initial UI work started. Work on test tool for interacting with test results repository coming along. Awaiting Linaro board approval for license. Please let me know if you have any questions. Cheers, Scott -- Scott Bambrough <scott.bambrough(a)linaro.org> Linaro Infrastructure Team Lead

14 years, 4 months

Linaro Feature Freeze in place

by Jamie Bennett

Hi, Linaro is now in Feature Freeze[1] and effort should switch to bug fixing and polish. If you believe that your new feature or package needs to be in the 10.11 Linaro release please follow the Feature Freeze Exception process [2] as soon as possible. Beta 1 is in 3 weeks [3] so please use this time to stabilize and improve what we already have in Linaro to ensure that the 10.11 release is as solid as possible. Regards, Jamie. -- Linaro Release Manager [1] https://wiki.linaro.org/Releases/FeatureFreeze [2] https://wiki.linaro.org/Releases/FreezeExceptionProcess [3] https://wiki.linaro.org/Releases/1011#Linaro10.11Schedule

14 years, 4 months

latest arm_next plus Ubuntu patches plus Linaro packaging

by John Rigby

There is a new linaro-linux kernel in the Linaro maintainers kernel ppa. It consists of: Nicos's linaro_merge_100811 merge of yesterday merged with Ubuntu-2.6.35-15.21 plus packaging stuff. The ppa url is:ppa:linaro-maintainers/kernel Here are all the details:https://launchpad.net/~linaro-maintainers/+archive/kernel/+sourcepu… This version has added a Versatile Express (vexpress) flavour in addition to the OMAP flavour that has been in previous releases. This kernel will be headed to the Ubuntu archive real soon now. A linux-linaro meta package is complete and about to be uploaded as well. If your would like to see the source for these check them out via gitweb here: http://git.linaro.org/gitweb?p=jcrigby/linux-linaro.git;a=summary and here: http://git.linaro.org/gitweb?p=jcrigby/linux-linaro-meta.git;a=summary Thanks John

14 years, 4 months

u-boot-linaro package available in linaro-maintainers kernel ppa

by John Rigby

A u-boot-linaro package is available in the linaro maintainers kernel ppa: ppa:linaro-maintainers/kernel The package is u-boot-linaro and the version is v2010.06-265-gcdb7497-linaro-1. If you just want to download the .deb and extract it by hand: https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/u-boot-lin… >From the changelog: u-boot-linaro (v2010.06-265-gcdb7497-linaro-1) maverick; urgency=low * Initial Linaro u-boot tree based on * Upstream v2010.06-265-gcdb7497 * A series of patches from ssakomans exp branch that add support for beagle C4 and xM. These have been rebased onto current upstream. The gitorious beagle trees are still based on v2010.03. These patches will be replaced with patches from ssakoman. * Versatile express patches from Matt Waddel. * Debian packaging by John Rigby based on the lucid u-boot-omap3 package. * Currently builds u-boot binaries for these platforms ca9x4_ct_vxp aka Versatile Express mx51evk aka Babbage omap4_panda omap3_beagle If you have access to any of these platforms your help with testing would be appreciated. If you would like other platforms added please let me know. Thanks John

14 years, 4 months

Images, apt-get clean and friends

by Christian Robottom Reis

Hi there! I unpacked our minimal release image and ran an xdiskusage on it, mostly to see what we're shipping -- and I was surprised to see that a fourth of the image is actually apt package caches and lists. Can we put into the image generation script something to strip them out before generating the image? The untarring also suggests a number of places where we could further trim the image, some of which are probably pretty hard to do: * stripping /usr/share/doc out (but everybody knew that) * dropping charmaps, zones and locale info that will never really be used * stripping out modules for devices that won't ever be on this ARM device * stripping out firmware for peripherals that won't ever be on this ARM device I've included the xdiskusage output so you can see what I mean. And good job on the release! -- Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko Linaro.org | [+55 16] 9112 6430 | http://async.com.br/~kiko

14 years, 4 months

RE: New "Linaro kernel merge result of the moment" aka "arm_next"

by Nicolas Pitre

On Wed, 11 Aug 2010, Will Deacon wrote: > Hi Nicolas, > > > The Linaro freeze is imminent, and at that point a stable branch that > > won't be rebased anymore will be forked. The stable branch should only > > see bug fixes and no new features. Therefore I'd like to know if there > > is anything that should be added or removed from this tree before the > > freeze is in place. Please tell me ASAP. > > The only thing I can think of from my end is the hardware breakpoint patches > I have: > > http://www.linux-arm.org/git?p=linux-2.6-wd.git;a=shortlog;h=refs/heads/hw-… > > I've not merged these into my Linaro branch because I'm not happy with the > amount of testing they've received [it's a bit of a catch 22 because one > good way to get them tested is to merge them!]. My criteria would be: 1) Could their addition break something else even when not used? If there is no risk for regression then we could as well just include them and add fixes later if need be. 2) Is there some ABI implied with gdb or the like? If there are ABI issues then I'd prefer having the assurance that it won't change by the time this gets merged into the mainline kernel. Nicolas

14 years, 4 months

A quick toolchain benchmark

by Michael Hope

I had a quick go at benchmarking the Linaro GCC compiler and was presently surprised. The workload was decoding 10 s of h.264 video using ffmpeg with assembly optimisations disabled. This gives the compiler a good workout. Compared to FSF GCC 4.4.4, Linaro GCC 4.4 is 6 % faster, FSF GCC 4.5.0 is 12 % faster, and Linaro GCC 4.5 is 24 % faster. Now this is with a sample size of one so the results are not statistically valid, and I haven't told you how to reproduce it so they're not scientifically valid, but the numbers are pleasing none the less. -- Michael

14 years, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev