April 2009 - elfutils-devel - Fedora mailing-lists

Status 2009-04-20
by Petr Machata 17 Jun '09

17 Jun '09

= Work done last couple weeks: * Time spent on elfutils: ~50%, had some RHEL & Fedora-related work to do. * Done rough testing, where I just wanted to swipe over all files and was filtering out messages using several broad regexes. Doing more elaborate testing now. The rejection rule is now composed of package regex, a message regex, and optional test scriptlet. The message is filtered out if the package regex matches package name, and if message regex matches the message. The scriptlet is run in that case, if present, to validate assumptions behind this rejection. (E.g. check that the section the message refers to is [^W]AX.) = Work scheduled next: * Expected time spent on elfutils: 80%. * Continue plowing through the results. * Roland, what's the next big item on our list? PM

2 8

About hidden & local symbols
by P J P 29 Apr '09

29 Apr '09

Hi, I came across a library `libexiv2.so'(www.exiv2.org) which has some hidden symbols in it. But the `Version symbol' entries for those hidden symbols are shown as - 1 *global* - by `eu-readelf -sV'. Now if symbol is hidden - shouldn't the highest(15'th) bit of the corresponding `Version symbol' entry be set? And if so, then it could not possibly equate to 1, right? The other thing I wanted to confirm was, - a binary(say tcpdump) is linked to a library(libpcap) which does not use Symbol Versioning and does not have `Version definition' section in it. In such a case, $ `eu-readelf -sV tcpdump' shows an output wherein, `Version symbol' entries for symbols defined in libpacp are shown as: 0 *local* . Which means the symbol is defined in the same object and is not accessible outside of the same, right? So could I infer that - `Version symbol' entries are greater than 1 if and only if the concerned library(or DSO) uses symbol versioning. - And if so, there is no way of knowing if a *local* symbol is defined in the same object/binary or is resolved from a library while running? Thank you. -- Regards - Prasad

3 5

[SPAM] Global Leadership in HandCare - Consumer, Professional and Industrial Products OTC : FLKI
by Communications Officer - International OptIN Customer Selection 29 Apr '09

29 Apr '09

1 0

[SPAM] The Next Billion Dollar Brand - Distribute IT OTC FLKI
by Communication Officer OptIN Customer Base 28 Apr '09

28 Apr '09

1 0

pmachata/reader_hooks review
by Roland McGrath 27 Apr '09

27 Apr '09

Defns have to do: int internal_function foo (...) i386 build will break with internal_function decls but not defns. s/dwarf_readhooks.c/libdw_relocate.c/ A dwarf_*.c name is for a file implementing a function of that name. All the calls seem to use a size == 8 expression for the bool argument. Just make it an offset/address size argument that is 4/8. s/addr/off/ in dwarf_formref_die, dwarf_getpubnames + Dwarf_Addr escape = addr64 ? (Elf64_Addr)-1 : (Elf64_Addr)(Elf32_Addr)-1; Write a libdwP.h macro for this (taking address_size rather than bool). It will be used again in dwarf_ranges. s/Dwarf_Word/Dwarf_Off/ for offset-flavored parameters. s/Dwarf_Word/Dwarf_Addr/ for address-flavored parameters. I don't think the names are too long. Let's use "address" and "offset". If it makes the decoder code nicer, define macros or static inlines "read_address" and "read_offset" (+"_inc") wrappers for convenience. (You might want to do that for the _inc flavors anyway, so the arithmetic inlines away.) Make read_offset also take an IDX_* argument for the referring section. If it's a macro, you can make the args short and use IDX_debug_##arg. + if (*offset >= data->d_size + || *offset + addr64 ? 8 : 4 >= data->d_size) Use: || data->d_size - offset_size < *offset) Don't call the addr function in the off function. Even as soon as the test code, they will be disjoint code paths. (A common local inline that has the size-check if clause and zero extension is fine of course.) Use const pointers everywhere. Two of these: + return -1l; Neither of those functions return long int. Use plain -1. Thanks, Roland

2 3

0.141
by Roland McGrath 23 Apr '09

23 Apr '09

I think we are about ready to go for 0.141 (a605a3c). I say wait til first thing Monday to give Mark a chance to yell (should be plenty of time given 9 hours between us). If no new fires, tag it. Remember: 1. autoreconf -f -i (do it on F-10 or later); make distcheck 2. git tag -s 3. gpg -b elfutils-0.141.tar.bz2 4. upload elfutils-0.141.tar.bz2{,.sig} 5. Now you can then immediately commit a configure.ac bump to 0.141.50 or .90 or something. Thanks, Roland

3 4

elfutils / man pages
by Andrew Hecox 23 Apr '09

23 Apr '09

there are no man pages in the current elfutils repo; is this an intentional design decision at this point or something that just hasn't gotten done? (volunteering to help for the latter case) -Andrew -- Andrew Hecox Technical Account Manager, Red Hat, Inc office: 919 754 4157, cell: 919 758 9234

2 8

0.141: hold the phone
by Roland McGrath 22 Apr '09

22 Apr '09

Uli isn't being real quick on the draw anyway, but we need to hold 0.141 for another day. I've just fixed another libdwfl bug (stap #10088). I'll recheck the test builds this afternoon. I'd like to get Mark to repeat his regression tests again. (Sorry!) This fix should be safe, but it is touching same of the same code that was affected in the fixes for Mark's issues. Thanks, Roland

2 5

elfutils status 2009-4-20
by Roland McGrath 20 Apr '09

20 Apr '09

Last week: Actual time spent on elfutils: ~50% * merged dwfl_module_getsym vs !SHF_ALLOC change (stap report) * fixed RHBZ#495213: eu-strip misbehavior * fixed RHBZ#494858: crash in core-file support * configury jiggery for _ELFUTILS_PREREQ in git/pre-release versions * nit fixes * 0.141 release ~ready * DwarfTasks update ** reloc-aware reader items ** C++ reloc support items * updated libdw CFI support (roland/unwind) branch, maybe merge soon? This week: Expected time spent on elfutils: 50% * 0.141 release -> fedorahosted, Fedora devel/11/10/9 * more DwarfTasks update ** reference equality plan ** writer components * post wrt writer component design * start some writer pieces

1 0

Another relocation oddness
by Petr Machata 20 Apr '09

20 Apr '09

Hi, In this file: kernel-debuginfo-2.6.29-0.258.rc8.git2.fc11.i586:usr:lib:debug:lib:modules:2.6.29-0.258.rc8.git2.fc11.i586:vmlinux I'm seeing relocations that seem wrong: the addend and the value of the symbol the relocation is done against are the same. Relocation section [71] '.rel.debug_aranges' for section [70] '.debug_aranges' at offset 0x4d1d0dc contains 4309 entries: Offset Type Value Name 0x00000006 386_32 0000000000 .debug_info 0x00000010 386_32 0xc0400000 .text.head Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 00000000 000000 000000 0 0 0 0 [ 1] .text.head PROGBITS c0400000 001000 0003b1 0 AX 0 0 16 [ 2] .rel.text.head REL 00000000 4b3313c 0001e0 8 87 1 4 [ 3] .text PROGBITS c0400400 001400 2f33ca 0 AX 0 0 128 Symbol table [87] '.symtab' contains 40473 entries: 29807 local symbols String table: [88] '.strtab' Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UNDEF 1: c0400000 0 SECTION LOCAL DEFAULT 1 2: c0400400 0 SECTION LOCAL DEFAULT 3 3: c06f37cc 0 SECTION LOCAL DEFAULT 5 And objdump just to be sure: Contents of section .debug_aranges: 0000 1c000000 02000000 00000400 00000000 ................ 0010 000040c0 b1030000 00000000 00000000 ..@............. 0020 1c000000 02007d00 00000400 00000000 ......}......... Unless I'm wrong here, what I see is relocation with addend 0xc0400000, formed against .text.head, whose address also is 0xc0400000, resulting in relocated address 0x180800000, or 0x80800000 after 32-bit wrapping (which I made up right now, dwarflint forgets to do this). That doesn't fall into any section. Bug, or am I missing something? PM

3 5

unwind branch review
by Roland McGrath 20 Apr '09

20 Apr '09

I've been poking at it again a bit lately, and, oddly enough, I think the roland/unwind branch might be more or less ready to merge on the trunk (perhaps as soon as 0.142). I'd appreciate some review of the branch code. The branch is really a misnomer, of course. It's not the "unwinder" branch, it's the CFI support branch. Like everything else in libdw, it is meant to be the right granular interface at the right level of abstraction for what the data is really about. So it does not do any "unwinding" at all. What this piece exposes is the "PC => {register #, location} map" mapping. That is, the static semantics view of CFI, using DWARF location expressions (or value expressions) in Dwarf_Op[] form. The "show me a backtrace in the core file/process" level of "unwinding" that everyone thinks about is in fact a composition of CFI interpretation, location expression evaluation, and register/memory gathering. What we have here is the first of those. This is the only piece we need for static DWARF tools like dwarfcmp and writer/compression support. I think the new libdw interfaces here are decent enough in C for simple support, and a sufficient foundation for the C++ interfaces to read and write this data. This is work I originally did a couple of years ago; I have updated it along the way, and cleaned up a bit more lately around the edges. But I haven't done a thorough review of all the code from scratch myself lately. So anything XXX-commented or unfinished-looking or otherwise questionable merits some fresh hashing out. Thanks, Roland $ git diff --stat origin/master..roland/unwind backends/ChangeLog | 10 + backends/Makefile.am | 4 +- backends/i386_cfi.c | 65 +++++ backends/i386_init.c | 1 + backends/x86_64_cfi.c | 60 +++++ backends/x86_64_init.c | 1 + libdw/ChangeLog | 54 +++++ libdw/Makefile.am | 10 +- libdw/cfi.c | 498 +++++++++++++++++++++++++++++++++++++++ libdw/cfi.h | 249 +++++++++++++++++++ libdw/cie.c | 193 +++++++++++++++ libdw/dwarf_begin_elf.c | 3 +- libdw/dwarf_cfi_addrframe.c | 78 ++++++ libdw/dwarf_cfi_end.c | 70 ++++++ libdw/dwarf_end.c | 8 +- libdw/dwarf_error.c | 1 + libdw/dwarf_frame_cfa.c | 100 ++++++++ libdw/dwarf_frame_info.c | 74 ++++++ libdw/dwarf_frame_register.c | 143 +++++++++++ libdw/dwarf_getcfi.c | 92 +++++++ libdw/dwarf_getcfi_elf.c | 331 ++++++++++++++++++++++++++ libdw/dwarf_getlocation.c | 75 +++++-- libdw/dwarf_next_cfi.c | 234 ++++++++++++++++++ libdw/encoded-value.h | 174 ++++++++++++++ libdw/fde.c | 297 +++++++++++++++++++++++ libdw/frame-cache.c | 87 +++++++ libdw/libdw.h | 158 ++++++++++++- libdw/libdw.map | 16 ++ libdw/libdwP.h | 15 +- libdw/memory-access.h | 37 ++- libdwfl/ChangeLog | 11 +- libdwfl/Makefile.am | 2 + libdwfl/dwfl_addrframe.c | 93 ++++++++ libdwfl/dwfl_module_dwarf_cfi.c | 89 +++++++ libdwfl/dwfl_module_eh_cfi.c | 75 ++++++ libdwfl/libdwfl.h | 23 ++ libdwfl/libdwflP.h | 10 + libebl/ChangeLog | 9 + libebl/Makefile.am | 2 +- libebl/ebl-hooks.h | 2 + libebl/eblabicfi.c | 63 +++++ libebl/eblopenbackend.c | 9 + libebl/libebl.h | 34 +++- libebl/libeblP.h | 6 + tests/ChangeLog | 6 + tests/Makefile.am | 3 +- tests/addrcfi.c | 191 +++++++++++++++ 47 files changed, 3720 insertions(+), 46 deletions(-)

1 0

release soon?
by Roland McGrath 17 Apr '09

17 Apr '09

I think we should do 0.141 after another day or two for testing and verification. It has some needed fixes, and makes two Fedora secondary arch ports newly happy. All looks good on my end. I'd like to let mjw verify that current git has the problems he hit in stap fixed (RHBZ#489439 and dwfl_module_getsym). "sed -i s/140/141/ configure.ac; autreconf" to test _ELFUTILS_PREREQ code. $ git log --abbrev-commit --pretty=oneline --reverse elfutils-0.140..master 8651c5e... Fix RHBZ#489439: dwfl_module_build_id yields wrong vaddr for prelinked DSO 329ed9f... __libdwfl_find_build_id optimization nit 6a4bdd9... Add DW_CFA_GNU_negative_offset_extended. d5ff667... Update elf.h and some tables; fill in sparc backend reloc table. dae7be7... Sending translation for po/es.po 4e1b7c9... Sending translation for po/de.po 243fa26... dwfl_module_getsym should not adjust symbols from non-SHF_ALLOC sections. 785dbb1... Fix double-adjust for ET_REL. 68f29f9... Make dwfl_module_getsym yield shndx -1 for any non-allocated section. ec84323... Sending translation for Spanish 04a1416... Fix strip -f infinite loop when coping with some extra kooky object sections. fa25326... Fix RHBZ#494858: fix bad address checks in core file support. 54eb890... NEWS items for notable changes since 0.140 94f4383... Fix error message. eb9ba47... Nominal ARM support. Thanks, Roland

3 6

Re: [RFC]: Feature to display local arguments and variables
by Dave Anderson 17 Apr '09

17 Apr '09

----- "Sharyathi Nagesh" <sharyath(a)in.ibm.com> wrote: > >> How to Build/Requirements > >> 1. Enable compiling extends option in main Makefile > > > > You mean to just enter "make extensions", right? > Yes, found the Makefile under extensions is not called due to this, we > faced this issue with crash 4.0.7.7 didn't try with latest crash > though. It's not a new concept. If the extensions/Makefile sees a "local.c" file, it will then look for a "local.mk" file and invoke it. I applied your patch, and "make extensions" from the top-level directory works as expected (although the compilation fails as expected): # make extensions gcc -nostartfiles -shared -rdynamic -o local.so local.c -fPIC -ldw -L ../../elfutils-0.137/libdw -I ../../elfutils-0.137/libdw -I ../../elfutils-0.137/libelf/ -DX86_64 -Wall; local.c:8:23: error: libdw.h: No such file or directory local.c:9:19: error: dwarf.h: No such file or directory local.c:11:21: error: netdump.h: No such file or directory local.c:33: error: expected ‘)’ before ‘*’ token ... > > > >> 2. create a symbolic link to netdump.h under extensions/ > > > > You should be able to do that in your local.mk file. > Ok, sure will take care of that. Please let us know of any reference > *.mk file that is used. will help as this will need to take care of > library dependencies in this file The extensions/sial.mk file is the only example in the upstream tree. Actually there are two alternatives: (1) as you are doing now, put your local.c and local.mk and whatever other files you need into an existing extensions subdirectory, or (2) build a standalone package that only requires the crash-devel subpackage. Alternative (2) allows you to create a standalone package that uses the crash-devel subpackage, which only consists of the "defs.h" file. Doing it that way you don't need the complete crash source tree. Your package is unique in that it currently needs "netdump.h" for the vmcore_data structure. I am not averse to moving that structure declaration into "defs.h" if you want to go that route. Check out the IBM crash-spu-commands-1.1-1.src.rpm package as an example of alternative (2): http://riksun.riken.go.jp/pub/pub/Linux/cern/updates/slc5X/SRPMS/crash-spu-… In any case, that's easy enough to deal with in the future. I'd just continue working in the extensions subdirectory for now. > >> 3. Context switching via -r command still needs to implemented > > > > BTW, the "placeholder" code in cmd_local() for -p and -r would be > > disastrous because they modify a context structure with a totally > > different pid. What you'll want to do is update local->tc with a > > pointer to the context of the entered pid argument. (There's helper > > functions to do that) > yes you are right initialize_local() function needs to handle it. > For -p opion we need > 1. function to provide task context for the pid passed That would be pid_to_context(). But more on that below... > 2. Current register context for the process, for Active process we > could get from ELF Notes, if there is a way to access register set for > these process it would be helpful The only register sets are found in the per-cpu NT_PRSTATUS notes in the ELF header. They don't exist for the other non-active tasks, and in fact, the older netdump format only contains a single ELF NT_PRSTATUS for the crashing cpu task. Furthermore, if the kdump vmcore is compressed with "makedumpfile -c", then the resultant dumpfile's unique non-ELF header doesn't even contain those register sets. > -c option allows user to shift context. If user changes active CPU via > set -c <new CPU>, local -c will allow user to move current local context > to that particular cpu context. > > Please Let us know your thoughts on this implementation I don't know why that would be necessary. When your cmd_local() function is called without "-p <pid>", it should just default to the current context which would have been set with the prior "set -c <cpu>", "set <task>" or "set <pid>". For that matter, why do you even need "-p <pid>"? I'm not clear on why you wouldn't be using the current context all of the time? It appears that your mechanism will only work if the target task is an active task whose register set is contained in the ELF header. So when your command is called, it seems like it would simply need to first determine "can I handle this context?", and if not, just bail out. Dave

1 0

Re: [RFC]: Feature to display local arguments and variables
by Dave Anderson 17 Apr '09

17 Apr '09

----- "Sharyathi Nagesh" <sharyath(a)in.ibm.com> wrote: > Hi > We have implemented this piece of code to provide, crash tool, > capability to display local variables and arguments. We would kindly > request you to provide your feedback and guidance on this code so that > we can take it further When I get a chance I'll reserve a ppc64 machine to give this a go. But for now, I've just got a few questions and suggestions. > > How to Build/Requirements > 1. Enable compiling extends option in main Makefile You mean to just enter "make extensions", right? > 2. create a symbolic link to netdump.h under extensions/ You should be able to do that in your local.mk file. > 3. This feature makes use of libelf and libdw libraries provided by elfutils package. > 4, This feature is implemented as an extend, local.so library needs to > be loaded once crash prompt is available > > Features > 1. Currently it has feature to display arguments/locals of top most > stack frame. ex usage: local params or local locals What function would be considered the "top most" stack frame, say if panic() were called, i.e., when crash_kexec() gets called with a NULL "regs" argument? It appears that it would be crash_kexec() itself. On the other hand, most dumps are generated from die(), but the regs have been passed through several functions, so it's not clear to me what you would see. For those of us who are ppc64-machine-challenged, a few examples would have been helpful... > 2. Currently code can analyze only ppc64 dumps > 3. It displays the current address of the local variables ( and some > times direct values when the variables are stored in register and not in > stack frame) > 4. In case of code optimization, variable information is not available > at that time printing "Failed to fetch information" (This is in > accordance with gdb out put) > > TBD > 1. Stack unwinding code is still need to be implemented > 2. Support for x86 dumps is still not provided BTW, have you explicitly left out x86_64? > 3. Context switching via -r command still needs to implemented BTW, the "placeholder" code in cmd_local() for -p and -r would be disastrous because they modify a context structure with a totally different pid. What you'll want to do is update local->tc with a pointer to the context of the entered pid argument. (There's helper functions to do that) > > Note: We were planning to display the variable values instead of > addresses as we are doing currently, but it adds up to additional > challenges in terms of typecasting the variables, in case it is array or > structure, so for the time being we are printing only address and expect > user to dump contents using rd command. Suggestions here will be very helpful. Presumably the user will know what the local data types are, and can simply display them using the "struct <datatype> <address>" command. Using rd is fine, but may be unnecessarily primative. But anyway, are you saying that the local variable data types cannot be determined from some dwarf interface? > > Attaching the code...but the Code is not extensively tested > please let us know your thoughts Another minor nit -- I'd prefer that a new function be added to netdump.c similar to get_kdump_vmcore_data() that you can use for "real" netdump dumpfiles -- if you are planning to actually planning to support netdump dumpfiles. Just create a new get_netdump_vmcore_data() instead of making the structure global. Anyway, it looks promising on paper! Thanks, Dave

2 1

DW_CIE_ID
by Roland McGrath 15 Apr '09

15 Apr '09

I'm not sure that DW_CIE_ID belongs in dwarf.h as it is. The CIE_id value is 0xffffffff only in 32-bit DWARF. In 64-bit DWARF, it's 0xffffffffffffffff. So there isn't a single value that is correct for DW_CIE_ID. In my unwind branch, I didn't add any CIE_id constant to dwarf.h at all. Instead, I only use a header parser (dwarf_next_cfi) that canonicalizes the CIE_id/CIE_pointer field to a Dwarf_Off (i.e. 64 bits) and so the single CIE_ID constant I provide is the 64-bit one. (That's all in unwind.h on the branch, but would go in libdw.h when merged.) But dwarf.h is for the literal format constants in raw form, not for canonicalized constants in the libdw interface. So if anything is in dwarf.h for this, I think it has to be both of the two variants with variant names. e.g. DW32_CIE_ID and DW64_CIE_ID. (Or maybe it's better to keep the uniform DW_ prefix and make them DW_CIE_ID_{32,64} or some other names.) i.e. like the patch below. This works fine for me, but I am a little worried that the 64-bit constant in an enum might upset the compiler (version or anality switch-set) used for some application's build. What say you? Thanks, Roland ====== diff --git a/libdw/dwarf.h b/libdw/dwarf.h index 3b9d40c..0000000 100644 --- a/libdw/dwarf.h +++ b/libdw/dwarf.h @@ -677,7 +677,8 @@ enum /* ID indicating CIE as opposed to FDE in .debug_frame. */ enum { - DW_CIE_ID = 0xffffffff + DW32_CIE_ID = 0xffffffff, + DW64_CIE_ID = 0xffffffffffffffff }; diff --git a/src/readelf.c b/src/readelf.c index f4ed033..0000000 100644 --- a/src/readelf.c +++ b/src/readelf.c @@ -4673,9 +4673,13 @@ print_debug_frame_section (Dwfl_Module * if (unlikely (cieend > dataend || readp + 8 > dataend)) goto invalid_data; - Dwarf_Word cie_id; + Dwarf_Off cie_id; if (length == 4) - cie_id = read_4ubyte_unaligned_inc (dbg, readp); + { + cie_id = read_4ubyte_unaligned_inc (dbg, readp); + if (!is_eh_frame && cie_id == DW32_CIE_ID) + cie_id = DW64_CIE_ID; + } else cie_id = read_8ubyte_unaligned_inc (dbg, readp); @@ -4686,7 +4690,7 @@ print_debug_frame_section (Dwfl_Module * Dwarf_Word initial_location = 0; Dwarf_Word vma_base = 0; - if (cie_id == (is_eh_frame ? 0 : DW_CIE_ID)) + if (cie_id == (is_eh_frame ? 0 : DW64_CIE_ID)) { uint_fast8_t version = *readp++; const char *const augmentation = (const char *) readp;

2 2

[RFC]: Feature to display local arguments and variables
by Sharyathi Nagesh 15 Apr '09

15 Apr '09

Hi We have implemented this piece of code to provide, crash tool, capability to display local variables and arguments. We would kindly request you to provide your feedback and guidance on this code so that we can take it further How to Build/Requirements 1. Enable compiling extends option in main Makefile 2. create a symbolic link to netdump.h under extensions/ 3. This feature makes use of libelf and libdw libraries provided by elfutils package. 4, This feature is implemented as an extend, local.so library needs to be loaded once crash prompt is available Features 1. Currently it has feature to display arguments/locals of top most stack frame. ex usage: local params or local locals 2. Currently code can analyze only ppc64 dumps 3. It displays the current address of the local variables ( and some times direct values when the variables are stored in register and not in stack frame) 4. In case of code optimization, variable information is not available at that time printing "Failed to fetch information" (This is in accordance with gdb out put) TBD 1. Stack unwinding code is still need to be implemented 2. Support for x86 dumps is still not provided 3. Context switching via -r command still needs to implemented Note: We were planning to display the variable values instead of addresses as we are doing currently, but it adds up to additional challenges in terms of typecasting the variables, in case it is array or structure, so for the time being we are printing only address and expect user to dump contents using rd command. Suggestions here will be very helpful. Attaching the code...but the Code is not extensively tested please let us know your thoughts Thanks Sharyathi Nagesh

1 0

elfutils status 2009-4-13
by Roland McGrath 13 Apr '09

13 Apr '09

The past is gone. I have nothing to report for my woeful lack of elfutils status reports since February. Some this and that here and there, not much. By next week I hope we'll get back to a coherent set of tasks for the near term and weekly progress tracking. This week: Expected time on elfutils: 50% * dwfl_module_getsym vs !SHF_ALLOC change (stap report) * RHBZ#495213: eu-strip misbehavior * RHBZ#494858: crash in core-file support * DwarfTasks update ** reloc-aware reader items ** C++ reloc support items ** reference equality plan ** writer components * post wrt writer component design

1 0

[SPAM] World Leadership in Professional & Industrial Hand Care OTC : FLKI
by Communication Officer OptIN Preferred Customers 10 Apr '09

10 Apr '09

1 0

relocation of DW_AT_low_pc against non-exec and/or non-alloc section
by Petr Machata 08 Apr '09

08 Apr '09

Hi, I'm getting a couple cases where a relocation of DW_AT_low_pc and DW_AT_high_pc attribute is formed against a section that's either non-EXEC, or even non-ALLOC. The case of non-EXEC is in .rodata of vmlinux. A single die that comes from arch/x86/kernel/trampoline_32.S has this property. So I shift my understanding of low_pc and high_pc from "we can expect PC to have this address" to "it's a place in address space". Another case is basically any GRUB module. These have relocations of low_pc and high_pc formed against .moddeps, which is non-ALLOC section (which, if I understand things correctly, means it doesn't end up in address space at all). So, is my ALLOC & EXEC expectation valid? If it's too strict, is any ALLOC section kosher, and GRUB modules are erroneous, or is any section at all kosher? PM

2 3

[SPAM] Visit Barcelona
by Visit Barcelona 06 Apr '09

06 Apr '09

1 0

[SPAM] Visit Barcelona
by Visit Barcelona 06 Apr '09

06 Apr '09

1 0

the reference equality conundrum
by Roland McGrath 01 Apr '09

01 Apr '09

In the C++ interface, we represent a reference-class attribute with a debug_info_entry::iterator. This works nicely for purposes of navigation. You can use it like a pointer to the debug_info_entry. But that doesn't help for the "semantic equality" check that we want in attribute::operator== as used by e.g. dwarfcmp. Pointer equality is not the right test when comparing references in two parallel DIE trees. So, what does "reference equality" mean for a comparison between two trees from two different DWARF files? This is not only part of making dwarfcmp do something useful, but also essential at the crux of the identification of duplicate trees that is what the compression plan is all about. At first blush, a simple answer is that two references are identical if the subtrees they point to are identical (by deep comparison). But for important semantic purposes, that definition is too generous. Consider a trivial C++ example: main.cc: namespace A { #include "foo.cc" }; namespace B { #include "foo.cc" }; A::foo var; foo.cc: struct foo { int x, y; }; This yields the DIE tree (omitting lots of the irrelevant detail): #a10: compile_unit{name="main.cc", ...} #a20: namespace{name="A", decl_file=["main.cc"], decl_line=1} #a30: structure_type{name="foo", decl_file=["foo.cc"], decl_line=1} ... #a40: namespace{name="B", decl_file=["main.cc"], decl_line=4} #a50: structure_type{name="foo", decl_file=["foo.cc"], decl_line=1} ... #a60: variable{name="var", location=..., type=#a50} Note the #a30 and #a50 subtrees are identical. Now compare a second file: main.cc: namespace A { #include "foo.cc" }; namespace B { #include "foo.cc" }; B::foo var; // <--- B:: vs A:: above (foo.cc same as above) This yields the corresponding DIE tree: #b10: compile_unit{name="main.cc", ...} #b20: namespace{name="A", decl_file=["main.cc"], decl_line=1} #b30: structure_type{name="foo", decl_file=["foo.cc"], decl_line=1} ... #b40: namespace{name="B", decl_file=["main.cc"], decl_line=4} #b50: structure_type{name="foo", decl_file=["foo.cc"], decl_line=1} ... #b60: variable{name="var", location=..., type=#b30} (The only difference from s/a/b/ is #b60:type.) Since #a30, #a50, #b30, and #b50 are all identical, #b60's type=#b30 matches #a60's type=#a50 and we would call #a10 and #b10 identical. But we know this is wrong. In #a60 type=#a50 is required and type=#a30 would not do, not because the subtrees pointed to differ, but because their contexts differ. Context matters: here it is the difference between resolving to A::foo and resolving to B::foo. We have to get this right for dwarfcmp to be right at its job of semantic equality comparison. Moreover, we need to get it right in deciding where we can really consolidate redundant DIE trees to effect compression via DW_AT_imported_unit pointers. Whenever there are refs pointing to both identical copies of a duplicated DIE, we have to be sure that those two refs should be equal before we can unify those two DIEs into one in the output. So, what should count as "equal context" for two DIEs? What comes to mind is the sequence of parent DIEs back to (but not including) the compile_unit. One thought was just to compare tags and names (or lack thereof). Another is to compare tags and all attributes. Or maybe somewhere in between. Are there attributes that are going to give us mismatches where we would like to consolidate? (DW_AT_sibling of course does not count.) This presupposes that one thing that does not matter is the ordering of a DIE among its parent's other children. DIE children certainly are ordered in DWARF, so it could very well matter in the abstract. I have the impression there are some arcane cases with C++ namespace and using declarations where that ordering is relevant to decoding the context. But I don't have any clear sense of that or any other case where this kind of ordering matters. That is, of course order matters all over, e.g. "void foo(int x, int y)" vs "void foo(int y, int x)" produces DIE trees that only differ (and importantly so) in the order of the two DW_TAG_formal_parameter children. But I don't see how you could have two {formal_parameter "x" child of subprogram "foo" child of CU} (say) with all matching attrs, to each of which different things had a ref attr, yet there could be both of them in the same (logical) CU such that a tree walk from the base of the CU to find the one the ref points to would be ambiguous. But I fear for some hairy corners about that. Clearly we would hamstring useful compression enormously if we count "equal context" only when the containing DIE was completely identical. That is probably in practice far worse than the most simple and naively conservative plan: considering two DIEs identical only when they are both immediate children of a compile_unit. That simple plan is definitely fine for C, and might even be OK for C++ though perhaps only in all but its most obscure corners. My inclination is to start out with the plan to ignore ordering for the "context equality" part of reference equality. Conversely, be conservative in excluding none of the rest of context: compare all attributes. In dwarfcmp, this means the references will pass equality comparison, but then the trees as a whole still won't pass when there is a child order difference. For compression, it might mean foregoing some cases (and leaving duplicate DIEs) where conflation of the two references so you can't distinguish which of the two original DIEs it means might be entirely harmless. Consider: a.c: void foo (void) { #include "b.c" #include "b.c" } b.c: { typedef int itype; itype x; bar (&x); } This will generate two almost-identical lexical_block subtrees that differ only in their PC attributes. This means the child DIEs for "itype", "x", etc. have to be duplicated, just so that a reference to the first lexical_block's "itype" will be distinct from a reference to the second lexical_block's "itype". It almost certainly never matters to distinguish them for this case. At a guess, cases like that don't seem real likely to appear in numbers. In the long run, we may want to address this with an extension form for two-pointer refs. That would allow the most aggressive DIE deduplication possible, consolidating all identical subtrees regardless of context. Then each ref itself gives not only the pointer to that DIE, but the pointer to the imported_unit DIE that is outermost among those in the logical walk you would do from the CU to arrive at the referenced DIE. That second ref disambiguates the direct DIE ref, so the two-pointer ref identifies which copy it would point to if the compressed form were splayed back out to the logical DIE view that inserts copies where DW_TAG_imported_unit appears. As an implementation matter, determining this "context" to compare will entail a lot of tree walking. This requires some caching, something like a reference tracker class that parameterizes the dwarf classes. This may add some complication to the definition of those whole class trees. I'd appreciate feedback on all this thinking. (I have thought a bit more than that about the implementation, too, though far from worked it all out.) Thanks, Roland

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel April 2009