elfutils-devel August 2009

elfutils-devel@lists.fedorahosted.org

24 participants
35 discussions

[PATCH] Additional support for arm.
by Kurt Roeckx 19 Sep '09

19 Sep '09

Hi, Here is a patch that adds additional support for the arm backend. One of the things it does it add support to see the difference between hard and soft floating point operations. Currently this is done by selecting a different return_value_location hook, which probably isn't a good long term solution, but the only way I can see without having to change all the backends. Most of this patch was written by Eugeniy Meshcheryakov <eugeniy.meshcheryakov(a)googlemail.com> with some minor changes from me. Kurt

2 4

supporting DW_OP_{implicit,stack}_value
by Mark Wielaard 18 Sep '09

18 Sep '09

Hi, Since the gcc vta branch now emits the new (Dwarf 4) DW_OP_stack_value and DW_OP_implicit_value operands I looked into supporting them. This is a little bit difficult since, especially DW_OP_implicit_value changes some assumptions (at least some of mine). Unlike what the current comment in dwarf.h says the value block of DW_OP_implicit_value isn't carried in a DW_FORM, but uses the "raw memory encoding of the target". At least that is what gcc seems to emit, and reading the spec, that does seem what was meant to happen. This is somewhat awkward since it means we don't have the context to interpret the value at this point. You could see what points to the location description and see what the type should be, but that might not always be simple, so you have to depend on the caller knowing what to do with the "raw memory encoding". 2009-07-19 Mark Wielaard <mjw(a)redhat.com> * dwarf.h: Correct description of DW_OP_implicit_value encoding. Making readelf support them isn't too hard. For DW_OP_stack_value it is simply listing the new opcode. For DW_OP_implicit_value it means just reading the length and the (non-encoded) value. The only difficult is whether or not the try to print the value in a decoded form when the length is known. My patch prints it decoded when it is [1,] 2, 4 or 8 bytes since it is most likely to be a value of a basic type, otherwise it just dumps it as a hex bytes as is. 2009-07-19 Mark Wielaard <mjw(a)redhat.com> * readelf.c (print_ops): Add handling of DW_OP_implicit_value and DW_OP_stack_value. Then we come to libdw getlocation() and things get a bit harder. Again DW_OP_stack_value isn't much trouble. It doesn't have any operands, so just return it as is when interning. But DW_OP_implicit_value is a bit of an issue, since we don't know the actual value (no DW_FORM, just raw bytes), there is no convenient way to store it. Also it can be of arbitrary length, and all we have are two Dwarf_Words. In theory we could just pass the length and the offset (already there in the Dwarf_Op) into the Dwarf_Block. But there are two issues with this. First, the offset is to the start of the DW_OP and there is no convenient way I know of for the caller to get the size of the length encoding, so it is hard to determine the actual offset (we could store the extra offset/length-size in the number2 Dwarf_Word though). Secondly I don't actually understand how the caller would get a handle to the Dwarf_Block the offset refers to. For dwarf_getlocation() it would be easy, just call dwarf_formblock() on the Dwarf_Attribute. But for dwarf_getlocation_addr() the caller would have to parse the location list themselves and hope they do it in the same order/preference that dwarf_getlocation_addr() does it. Or am I missing some simple method to get at the Dwarf_Block that the Dwarf_Op array that dwarf_getlocation_addr() returns refer to? So for now I just store the length as number and the actual address into the Dwarf_Block data where the raw memory representation starts into number2. But this feels a bit like cheating, since it isn't really interning the DW_OP data since it depends on having the pointer into the data around. 2009-07-20 Mark Wielaard <mjw(a)redhat.com> * dwarf_getlocation.c (__libdw_intern_expression): Handle DW_OP_stack_value and DW_OP_implicit_value. Cheers, Mark

4 25

2009-08-31 Status
by Petr Machata 31 Aug '09

31 Aug '09

Last week --------- Time spent on elfutils: 70% Work on output. * Drop DWARF4 bits that I've had in before for experimenting (e.g. DW_FORM_flag_present, to check that the optimal form selection works for extreme cases). * Emit short strings inline. All strings that are shorter than the reference size are "short strings". * Several passes of simplifying code and moving stuff to more private (i.e. more writer-specific) places. Certain pieces of code may have to be reintroduced later, but now they are overkill and just obfuscate the code. * dwarf_64 is used throughout. If value doesn't fit into form that could be expanded by having dwarf_64==true, an exception is thrown. * Found a bug that causes that DW_AT_sibling would be emitted superfluously or omitted. It turned out that my understanding of _m_with_sibling was wrong, and that _m_w_s[true] and _m_w_s[false] can be true simultaneously. Well, that explains the data type used. Somehow I managed to get lost in the code for the rest of Friday, unable to get it right, hitting obscure errors. It's all on pmachata/dwarf-writer. This week --------- Already done: * Fix that stupid problem from Friday. I just scratched and rewrote it and it worked basically on the first try. Don't know what the big deal was. * Merge in dwarf branch. Rest of the week: We now emit strings and numbers with optimal forms. - Implement duplicate pruning, right now each die gets its own abbrev. - FYI, no computation is done whether it is advantageous to emit the abbrev in the first place (i.e. whether the savings of extra form outweigh price of the abbrev itself). That problem won't be tackled on Roland's advice. When the above is done, next thing might be optimizing references. For things we can't optimize, references including, we now pick the biggest form available. We can shrink these fields afterwards. But the codebase is not ready for this, e.g. gaps have to be able to move, size of ElfData has to be patched, etc. So perhaps work on preparing these bits, they will be useful later. Another option is work on making the produced data complete and well-defined enough for consumption by libdw. That may require emitting some tables in addition to .debug_info, .debug_abbrev and .debug_str. PM

1 0

Ted to the cult of intellectual beauty, an
by Raffa 30 Aug '09

30 Aug '09

Lf, with the assistance of an old, near-sighted negro. I remained continually in the room of the dead. I trembled lest something out of the way should be discovered. I wanted to assure myself that no mistrust could be read upon the faces of the others; but I did not dare to look any person in the eye. Everything made me impatient; the going and co

1 0

ted;' an
by Lazares 29 Aug '09

29 Aug '09

series of rhymes more than once in the same canto; and, from the structure of the _terza rima_, it is impossible to introduce any fresh matter when the canto is once completed without violating this rule. This fact alone serves to convict of forgery the unknown person who inserted eighteen lines after _Hell_, xxxiii. 90, in one of the Bodleian manuscr

1 0

d their midnight revels, and to fea
by McCollom 29 Aug '09

29 Aug '09

part is consigned to the engine. Engines are here manufactured from one horse to two hundred horse power, all acting together. Handsworth common being inclosed, enabled Mr. Boulton to extend his grounds to a considerable degree, which form an agreeable separation from his own residence, and forms a much admired scene of picturesque beauty. A person wandering through these secluded walks, or on the banks of the various lakes and water falls, which adorn them, may here enjoy the sweets of solitude and retirement, with equal composure, as if he was far distant

1 0

[SPAM] Ltering her prospects; but after acting as chief mourner t
by Yancey 28 Aug '09

28 Aug '09

Pliments are exchanged, and appointments made. Meanwhile masses are being said at all the side altars, which are surrounded by knots of people who fall on their knees at the sound of a little bell, and say their prayers quite undisturbed by the general murmur going on around them. "Presently there is a stir in the crowd surrounding the choir chapel; the organ is at its loudest, and then comes a long procession of vergers in purple and scarlet facings, and cross and torch bearers, and censer bearers, and acolytes and deacons and priests and canons and bishops, and a red-robed cardinal in vestments of cloth of gold wrought and figured with many a sacred sign, and, moreover, adorned with precious stones; and High Mass at St. Peter's, on Christmas Day, is at an end. "During the day most of the shops and all the Government offices were open. Soldiers were drilled all day long in the Piazza Vittorio Emanuele, and were formally marched to their various barr

1 0

[SPAM] Here must be many interesting cases--quite romances. Do tell us someth
by Sanjose 27 Aug '09

27 Aug '09

Sited? Where had the passengers been taken on? None since Alexandria? Humph! Alexandria was considered an infected port at present. Any one ill on board? No? Where, then, were the remaining members of the party? In their cabins? The doctor must ask, as a mere matter of form, to see them. Roger Broom's lips were suddenly compressed. So this was the game. He saw it all now. The doctor was in the plot. He meant to detain the yacht in quarantine. If he succeeded in doing this, Maxime Dalahaide was lost. Everything else they had thought of, but not this. "May I speak with you alone, Miss Beverly?" Loria had begun to plead, the instant he had set foot on deck. "Believe me, it is partly for your own sake, partly for the sake of others whose welfare is dear to you, that I ask it." It was the thing for which Virginia had been wishing. "Come down with me into the saloon," she said. "Could we not speak here, at a little distance from the others?"

1 0

[patch] Initialize input_pos
by Mark Wielaard 27 Aug '09

27 Aug '09

Hi, My gcc cannot figure out how input_pos can always be initialized: gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -I. -I/home/mark/src/elfutils/libdwfl -I.. -I. -I/home/mark/src/elfutils/libdwfl -I/home/mark/src/elfutils/libdwfl/../libelf -I/home/mark/src/elfutils/libdwfl/../libebl -I/home/mark/src/elfutils/libdwfl/../libdw -I.. -I/home/mark/src/elfutils/libdwfl/../lib -Wall -Werror -Wshadow -Wunused -Wformat=2 -Wextra -std=gnu99 -g -O2 -MT bzip2.o -MD -MP -MF .deps/bzip2.Tpo -c -o bzip2.o /home/mark/src/elfutils/libdwfl/bzip2.c cc1: warnings being treated as errors In file included from /home/mark/src/elfutils/libdwfl/bzip2.c:4: /home/mark/src/elfutils/libdwfl/gzip.c: In function ‘__libdw_bunzip2’: /home/mark/src/elfutils/libdwfl/gzip.c:179: error: ‘input_pos’ may be used uninitialized in this function make[2]: *** [bzip2.o] Error 1 I think it is right. input_pos should be explicitly initialized to zero when mmaped is set. The attached patch does this. OK to commit? Thanks, Mark

2 1

2009-08-24 Status
by Petr Machata 27 Aug '09

27 Aug '09

Last 2 weeks ------------ Time spent on elfutils: 60-70% Work on output. * Small fixes etc. * Output of VS_constant blocks * Allow recomputation of back-patches. Used to emit correct CU-local references, the recomputation being a simple subtraction of CU offset from the patch value. * Now generates abbreviations. Currently one abbrev per unique DIE, no merging is done. The best available form is picked for attributes that we _can_ optimize (e.g. constants, flags, data, but e.g. not references, since we don't know how the DIEs will end up being laid out. Also not strings, that will need string gathering pass). * Merged in `dwarf' branch with Roland's work. And dwarflint: * Rewrite of read_die_chain value validation. The amount of code is roughly the same, but the code is more extensible and clearer. * Support DW_FORM_sec_offset, DW_FORM_flag_present from DWARF4 It's all on pmachata/dwarf-writer. This week --------- My vague plan for what to do next revolves around figuring out how to do the low-level optimization properly. There are some moving parts that influence each other. For example, whether it is advantageous to emit string as strp vs. inline string depends on how many times does this string appear, and thus depends on the way we do the dissection of the DIE tree into partial CUs. On the other hand, the decision whether it is advantageous to dissect a DIE sub-tree into own partial unit, is dependent on forms that we use to store the attributes, and therefore links back to the string/strp problem. There are more instances of this problem pattern. Or perhaps there's a certain point where dissecting the tree is always advantageous, and this can be used as a starting point in some sort of iterative approach. Oh, and everything is still coded with xxx instead of proper dwarf_64 handling. We never do the 32-to-64-bit transition. I think that DWARF files that big won't really be common, I wonder if there are any in Fedora at all. We can take the approach of trying to emit it 32-bit, and when we find that we can't encode some DIE reference in 32bit quantity, we simply restart the process with dwarf_64 == true. There will be a command-line switch for users who know that their files don't fit 32-bit limit, that will also be useful for testing emitting and consumption of 64-bit DWARF files. PM

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel August 2009