Status 2009-04-20
by Petr Machata
= 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
14 years, 9 months
About hidden & local symbols
by P J P
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
14 years, 10 months
pmachata/reader_hooks review
by Roland McGrath
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
14 years, 10 months
0.141
by Roland McGrath
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
14 years, 11 months
elfutils / man pages
by Andrew Hecox
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
14 years, 11 months
0.141: hold the phone
by Roland McGrath
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
14 years, 11 months
elfutils status 2009-4-20
by Roland McGrath
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
14 years, 11 months
Another relocation oddness
by Petr Machata
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
14 years, 11 months