Summary: | sys-libs/glibc-2.17 with FEATURES=splitdebug and build-id - This package installs one or more files containing line ending characters | ||
---|---|---|---|
Product: | Portage Development | Reporter: | iGentoo <AlphatPC> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 462382 | ||
Attachments: |
glibc-2.17-build.log.xz
/var/tmp/portage/sys-libs/glibc-2.17/image/lib64/libc-2.17.so.xz workaround patch workaround patch workaround patch |
Description
iGentoo
2013-03-06 09:41:17 UTC
Created attachment 341092 [details]
glibc-2.17-build.log.xz
Created attachment 341094 [details]
/var/tmp/portage/sys-libs/glibc-2.17/image/lib64/libc-2.17.so.xz
Created attachment 341096 [details, diff]
workaround patch
(In reply to comment #3) > Created attachment 341096 [details, diff] [details, diff] > workaround patch Does the .note.gnu.gold-version hunk have anything to do with this bug? If not, then I would like to commit it as a separate patch. Fo the buildid parsing, it would be nice to see some sample readelf output, in order to clarify what we're fixing here. Are you sure that it's a good idea to die if the buildid is not exactly 40 characters long? (In reply to comment #4) > Fo the buildid parsing, it would be nice to see some sample readelf output, > in order to clarify what we're fixing here. Are you sure that it's a good > idea to die if the buildid is not exactly 40 characters long? Now I see you output in comment #0, and your changes to buildid parsing do seem reasonable to me now. Created attachment 341156 [details, diff]
workaround patch
(In reply to comment #4) > (In reply to comment #3) > > Created attachment 341096 [details, diff] [details, diff] [details, diff] > > workaround patch > > Does the .note.gnu.gold-version hunk have anything to do with this bug? If > not, then I would like to commit it as a separate patch. > > Fo the buildid parsing, it would be nice to see some sample readelf output, > in order to clarify what we're fixing here. Are you sure that it's a good > idea to die if the buildid is not exactly 40 characters long? -Wl,--build-id=none -> 0 character long. -Wl,--build-id=sha1 -> 40 characters long. -Wl,--build-id=md5 -> 33 characters long... I'm sorry, buildid(md5) should be 32 characters long.(In reply to comment #7) > (In reply to comment #4) > > (In reply to comment #3) > > > Created attachment 341096 [details, diff] [details, diff] [details, diff] [details, diff] > > > workaround patch > > > > Does the .note.gnu.gold-version hunk have anything to do with this bug? If > > not, then I would like to commit it as a separate patch. > > > > Fo the buildid parsing, it would be nice to see some sample readelf output, > > in order to clarify what we're fixing here. Are you sure that it's a good > > idea to die if the buildid is not exactly 40 characters long? > > -Wl,--build-id=none -> 0 character long. > -Wl,--build-id=sha1 -> 40 characters long. > -Wl,--build-id=md5 -> 33 characters long... I'm sorry, buildid(md5) should be 32 characters long. (In reply to comment #8) > > -Wl,--build-id=none -> 0 character long. > > -Wl,--build-id=sha1 -> 40 characters long. > > -Wl,--build-id=md5 -> 33 characters long... > > I'm sorry, buildid(md5) should be 32 characters long. Okay, so for md5, that last print $2 is undesirable then? I guess it would help if we looked at some kind of specification for this .note.gnu.build-id data. Without looking at a spec, using the "............GNU." pattern feels unreliable too. Maybe we should be matching against the corresponding hex string instead? The current code was added by vapier here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d4fdc3f5c04e556ce217e004ed461c9f05146c0f @vapier: got any insight for us? Here's the relevent code from debugedit: /* Look for a build-ID note here. */ Elf_Data *data = elf_rawdata (elf_getscn (dso->elf, i), NULL); Elf32_Nhdr nh; Elf_Data dst = { .d_version = EV_CURRENT, .d_type = ELF_T_NHDR, .d_buf = &nh, .d_size = sizeof nh }; Elf_Data src = dst; src.d_buf = data->d_buf; assert (sizeof (Elf32_Nhdr) == sizeof (Elf64_Nhdr)); while ((char *) data->d_buf + data->d_size - (char *) src.d_buf > (int) sizeof nh && elf32_xlatetom (&dst, &src, dso->ehdr.e_ident[EI_DATA])) { Elf32_Word len = sizeof nh + nh.n_namesz; len = (len + 3) & ~3; if (nh.n_namesz == sizeof "GNU" && nh.n_type == 3 && !memcmp ((char *) src.d_buf + sizeof nh, "GNU", sizeof "GNU")) { build_id = data; build_id_offset = (char *) src.d_buf + len - (char *) data->d_buf; build_id_size = nh.n_descsz; break; } len += nh.n_descsz; len = (len + 3) & ~3; src.d_buf = (char *) src.d_buf + len; } Created attachment 341974 [details, diff]
workaround patch
A way to get the first build-id...
readelf -n /lib/libc-*.so | awk '/Build ID:/{ print $NF; exit }'
(In reply to comment #11) > Created attachment 341974 [details, diff] [details, diff] > workaround patch Thanks, your changes are in these 3 commits: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c37c809c89a0ce0ccaef1a38599bc00afbca1179 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f87e325263df8c134e4b4cfe3837ae732bc9da2b http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c1015ee592de1804c1100b5c0d70865579c72b6e This is fixed in 2.1.11.56 and 2.2.0_alpha167. |