Though overall activity has been fairly low since about last March (wonder why ;-), there has been more than enough change to warrant a release. In particular 0.152 doesn't build happily with the newest compilers.
In the absence of strenuous and explained objection, I'm going to merge the robustify branch into the trunk.
I've just completed -D/-U support in ar/ranlib and the --enable-deterministic-archvies configure option, for parity with current binutils.
Mark is going to look into a new elflint-self regression on Fedora 17. Chances are that is a toolchain bug rather than something for us to fix. But it needs figured out before we consider a release.
I don't know of anything else anyone intends to work on any time soon. If you have any plans, please post about them.
Once Mark's investigation comes to a conclusion, I think we should do 0.153.
Thanks, Roland
Using gcc-4.6.2-1.fc16.x86_64 on HEAD (commit 3284b799), I get:
make[2]: Entering directory `/home/jistone/src/elfutils/src' gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/local/share/locale"' -DDEBUGPRED=0 -DSRCDIR="/home/jistone/src/elfutils/src" -DOBJDIR="/home/jistone/src/elfutils/src" -I. -I.. -I. -I. -I../lib -I.. -I./../libelf -I./../libebl -I./../libdw -I./../libdwfl -I./../libasm -std=gnu99 -Wall -Wshadow -Werror -Wunused -Wextra -Wformat=2 -g -O2 -MT arlib-argp.o -MD -MP -MF .deps/arlib-argp.Tpo -c -o arlib-argp.o arlib-argp.c arlib-argp.c:100:5: error: missing initializer [-Werror=missing-field-initializers] arlib-argp.c:100:5: error: (near initialization for ‘arlib_argp_children[1].flags’) [-Werror=missing-field-initializers] cc1: all warnings being treated as errors
Wacky. I'm building with GCC trunk and not getting that. But I fixed it anyway (5bdee8e).
Thanks, Roland
On Fri, Jan 20, 2012 at 01:05:04PM -0800, Roland McGrath wrote:
Though overall activity has been fairly low since about last March (wonder why ;-), there has been more than enough change to warrant a release. In particular 0.152 doesn't build happily with the newest compilers.
I added some NEWS entries for libdwfl, readelf, strip and dwarf.h to show what else has improved since 0.153. There also have been various smaller bug fixes. 0.153 NEWS section now looks as follows:
Version 0.153
libdw: Support reading .zdebug_* DWARF sections compressed via zlib.
libdwfl: Speed up dwfl_module_addrsym.
nm: Support C++ demangling.
ar: Support D modifier for "deterministic output" with no uid/gid/mtime info. The U modifier is the inverse. elfutils can be configured with the --enable-deterministic-archives option to make the D behavior the default when U is not specified.
ranlib: Support -D and -U flags with same meaning.
readelf: Improve output of -wline. Add support for printing SDT elf notes. Add printing of .gdb_index section.
strip: Add --reloc-debug-sections option. Improved SHT_GROUP sections handling.
Add support for typed dwarf stack, call_site and entry_value to dwarf.h and readelf.
I added some NEWS entries for libdwfl, readelf, strip and dwarf.h to show what else has improved since 0.153. There also have been various smaller bug fixes. 0.153 NEWS section now looks as follows:
I made some slight cosmetic cleanups to the text. Always put DWARF in all caps in all documentary text.
There's usually no need for NEWS items for bug fixes.
Ulrich just added his --color support but didn't add any NEWS items (nor comment on this mailing list). It seems dubious to me that --color=always be the default. I hate that crap altogether myself, but --color=auto seems like a safe default to keep tools script-friendly. (Not that anyone's existing scripts are really using eu-nm or eu-objdump, but IMHO at least eu-nm should endeavor to be compatible with scripting uses of binutils nm.)
Thanks, Roland
On Mon, Jan 23, 2012 at 13:39, Roland McGrath roland@hack.frob.com wrote:
It seems dubious to me that --color=always be the default.
Read the code again. If no --color argument is used no color will be used. That's the default. 'always' is just the default in case --color is used without the optional argument.
On Fri, Jan 20, 2012 at 01:05:04PM -0800, Roland McGrath wrote:
Mark is going to look into a new elflint-self regression on Fedora 17. Chances are that is a toolchain bug rather than something for us to fix. But it needs figured out before we consider a release.
The issue is as follows on x86_64 with gcc (GCC) 4.7.0 20120119 (Red Hat 4.7.0-0.8) and binutils-2.22-4.fc17.x86_64 any program will have a __TMC_END__ symbol in .symtab that looks as follows: 66: 0000000000600850 0 OBJECT GLOBAL HIDDEN 24 __TMC_END__ Section 24 is: [24] .data PROGBITS 0000000000600848 00000848 00000004 0 WA 0 0 4 So the address of __TMC_END__ is just beyond the end of the .data section.
__TMC_END__ comes from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/crtend.o 12: 0000000000000000 0 OBJECT GLOBAL HIDDEN 6 __TMC_END__ [ 6] .tm_clone_table PROGBITS 0000000000000000 00000050 00000000 0 WA 0 0 8
I assume this is a linker bug. In elflint we already have special cases for some issues with gnu ld for this particular error:
if (sym->st_value - sh_addr > destshdr->sh_size) { /* GNU ld has severe bugs. When it decides to remove empty sections it leaves symbols referencing them behind. These are symbols in .symtab. */ if (!gnuld || strcmp (section_name (ebl, idx), ".symtab") || (strcmp (name, "__preinit_array_start") != 0 && strcmp (name, "__preinit_array_end") != 0 && strcmp (name, "__init_array_start") != 0 && strcmp (name, "__init_array_end") != 0 && strcmp (name, "__fini_array_start") != 0 && strcmp (name, "__fini_array_end") != 0)) ERROR (gettext ("\ section [%2d] '%s': symbol %zu: st_value out of bounds\n"), idx, section_name (ebl, idx), cnt); }
Do we want an extra special case, or shall I file a bug report against gnu ld?
Cheers,
Mark
The issue is as follows on x86_64 with gcc (GCC) 4.7.0 20120119 (Red Hat 4.7.0-0.8) and binutils-2.22-4.fc17.x86_64 any program will have a __TMC_END__ symbol in .symtab that looks as follows: 66: 0000000000600850 0 OBJECT GLOBAL HIDDEN 24 __TMC_END__ Section 24 is: [24] .data PROGBITS 0000000000600848 00000848 00000004 0 WA 0 0 4 So the address of __TMC_END__ is just beyond the end of the .data section.
An address literally at the end of the section is OK, and elflint will already accept that. This is 8 bytes past, which seems pretty unlikely to be anything kosher.
__TMC_END__ comes from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/crtend.o 12: 0000000000000000 0 OBJECT GLOBAL HIDDEN 6 __TMC_END__ [ 6] .tm_clone_table PROGBITS 0000000000000000 00000050 00000000 0 WA 0 0 8
Given this, it seems like it's got to be a linker bug. Since this is effectively a new regression, I'd say you should pursue getting the linker bug fixed. If there is some good reason that can't get resolved failry quickly, then we could add a known-bug exception for --gnu-ld mode.
Thanks, Roland
On Mon, Jan 23, 2012 at 10:50:17AM -0800, Roland McGrath wrote:
Given this, it seems like it's got to be a linker bug. Since this is effectively a new regression, I'd say you should pursue getting the linker bug fixed. If there is some good reason that can't get resolved failry quickly, then we could add a known-bug exception for --gnu-ld mode.
I don't fully understand why/what is happening, but I filed a bug report against binutils ld with a reproducer that triggers the same thing with gcc < 4.7. http://sourceware.org/bugzilla/show_bug.cgi?id=13621
Cheers,
Mark
I don't fully understand why/what is happening, but I filed a bug report against binutils ld with a reproducer that triggers the same thing with gcc < 4.7. http://sourceware.org/bugzilla/show_bug.cgi?id=13621
The linker behavior is certainly buggy. But I also don't see off hand why __TMC_END__ needs to be global at all. If it were just a local symbol like __TMC_LIST__ is, then it would just be swallowed entirely when the section is empty.
Thanks, Roland
On Thu, Jan 26, 2012 at 01:23:23PM -0800, Roland McGrath wrote:
I don't fully understand why/what is happening, but I filed a bug report against binutils ld with a reproducer that triggers the same thing with gcc < 4.7. http://sourceware.org/bugzilla/show_bug.cgi?id=13621
The linker behavior is certainly buggy. But I also don't see off hand why __TMC_END__ needs to be global at all. If it were just a local symbol like __TMC_LIST__ is, then it would just be swallowed entirely when the section is empty.
It needs to be because it is used in different .o files (crtbegin.o and crtend.o). Both Richard and I came up with some workaround for GNU ld (although admittedly my patch doesn't really work in the more complex case), but we have some trouble convincing Alan Modra there is a real issue. Feel free to join the fun :) http://sourceware.org/ml/binutils/2012-01/msg00269.html
Cheers,
Mark
On Fri, Jan 20, 2012 at 01:05:04PM -0800, Roland McGrath wrote:
I don't know of anything else anyone intends to work on any time soon. If you have any plans, please post about them.
I like to see a new release soon, but I had one little patchlet.
In Dwarf 4 there is the new DW_FORM_sec_offset which replaces either DW_FORM_data4 or DW_FORM_data8 for section offsets. But dwarf_formudata doesn't recognize it. That means you cannot easily get at offset values like you could with Dwarf 3. I needed it recently when looking for .debug_ranges index sharing in DIEs. There is a "workaround" that readelf uses:
case DW_FORM_sec_offset: attrp->form = cbargs->offset_size == 8 ? DW_FORM_data8 : DW_FORM_data4; /* Fall through. */
case DW_FORM_udata: case DW_FORM_sdata: case DW_FORM_data8: case DW_FORM_data4: case DW_FORM_data2: case DW_FORM_data1:; Dwarf_Word num; if (unlikely (dwarf_formudata (attrp, &num) != 0)) goto attrval_out;
But that is slightly ugly and requires you keep track of the offset_size of the cu (which libdw gives you, but requires some extra work with libdwfl). So I would like to just accept DW_FORM_sec_offset in dwarf_formudata.
Does that look sane, or do you want a specific dwarf_formsec_off function for that?
Thanks,
Mark
I'm somewhat ambivalent about the API. I don't really like reading a section offset as if it were an uninterpreted integer. OTOH, it does seem useful to have a low-level interface for getting such an offset, and at that level it is close to be an uninterpreted integer. It's unfortunate that they overloaded a single form instead of going with per-target-section forms: it means a low-level accessor has no way to validate the datum.
Since these used to use the data forms before DWARF 3, I can't really decide whether it is a good convenience to let you read them that way, or it's propagating a bad overloading.
As to the implementation, it can't use __libdw_read_address. It needs to be __libdw_read_offset or at least something using __libdw_relocate_offset. Otherwise it won't do the relocation handling the right way whenever we switch that stuff on.
Thanks, Roland
On Mon, Jan 23, 2012 at 11:00:43AM -0800, Roland McGrath wrote:
I'm somewhat ambivalent about the API. I don't really like reading a section offset as if it were an uninterpreted integer. OTOH, it does seem useful to have a low-level interface for getting such an offset, and at that level it is close to be an uninterpreted integer. It's unfortunate that they overloaded a single form instead of going with per-target-section forms: it means a low-level accessor has no way to validate the datum.
Yes, but this isn't different from the old DW_FORM_data4/8. And in a lot of cases you do need to know which attribute you are using to validate or interpret form data.
Since these used to use the data forms before DWARF 3, I can't really decide whether it is a good convenience to let you read them that way, or it's propagating a bad overloading.
The documentation of dwarf_formudata () says: /* Return unsigned constant represented by attribute. */ which I interpreted as "give me the form data as if it is an unsigned constant, I know that it is one in this context".
As to the implementation, it can't use __libdw_read_address. It needs to be __libdw_read_offset or at least something using __libdw_relocate_offset. Otherwise it won't do the relocation handling the right way whenever we switch that stuff on.
Are you sure? For DW_FORM_data4/8 we already use __libdw_read_address. I might be missing something, but that seems correct because it uses the relocation handling hooks already. If that wasn't correct the previous workaround for reading DW_FORM_sec_offset by tweaking the Dwarf_Attribute form field (setting it to data4/8) was also incorrect. Is it?
Thanks,
Mark
Yes, but this isn't different from the old DW_FORM_data4/8.
It's different in that with DW_FORM_data* you can't do any better because you have zero information about what the meaning of the integer is. With DW_FORM_sec_offset, we know it has to be an offset into some DWARF section.
Hence it becomes reasonable to consider an API wherein you have to say which section it refers to. It would be a no-brainer if IDX_* were part of the public API. (Frankly IMHO it's a no-brainer that when DWARF introduced DW_FORM_sec_offset they should have added the ten distinct forms for the different target sections, it's not like we're really in danger of running out of form codes. But they didn't ask me.)
And in a lot of cases you do need to know which attribute you are using to validate or interpret form data.
That's certainly true. Sometimes that might mean that the API should require that knowledge of its caller. The IDX_* values aren't part of the API and I don't think we want them to be. But we can use DW_AT_* constants as proxies--and we already know the one in question in this interface. So without even changing the API, we can make this call smart about use of DW_FORM_sec_offset. We just need some more internal knowledge about which attributes refer to which sections.
Since these used to use the data forms before DWARF 3, I can't really decide whether it is a good convenience to let you read them that way, or it's propagating a bad overloading.
The documentation of dwarf_formudata () says: /* Return unsigned constant represented by attribute. */ which I interpreted as "give me the form data as if it is an unsigned constant, I know that it is one in this context".
Well, that doesn't mean you can read DW_FORM_addr or DW_FORM_strp or DW_FORM_ref* this way. It means the attribute should have one of the DW_FORM_*data* forms, and you want to treat its value as unsigned.
As to the implementation, it can't use __libdw_read_address. It needs to be __libdw_read_offset or at least something using __libdw_relocate_offset. Otherwise it won't do the relocation handling the right way whenever we switch that stuff on.
Are you sure? For DW_FORM_data4/8 we already use __libdw_read_address. I might be missing something, but that seems correct because it uses the relocation handling hooks already. If that wasn't correct the previous workaround for reading DW_FORM_sec_offset by tweaking the Dwarf_Attribute form field (setting it to data4/8) was also incorrect. Is it?
address!=offset. This is all moot in the trunk, since they're both no-ops. But in the roland/relocate branch you'll see the difference. The kinds of relocs that are valid for an address are different from those for an offset.
Thanks, Roland
On Thu, 2012-01-26 at 13:53 -0800, Roland McGrath wrote:
Hence it becomes reasonable to consider an API wherein you have to say which section it refers to. It would be a no-brainer if IDX_* were part of the public API. (Frankly IMHO it's a no-brainer that when DWARF introduced DW_FORM_sec_offset they should have added the ten distinct forms for the different target sections, it's not like we're really in danger of running out of form codes. But they didn't ask me.)
And in a lot of cases you do need to know which attribute you are using to validate or interpret form data.
That's certainly true. Sometimes that might mean that the API should require that knowledge of its caller. The IDX_* values aren't part of the API and I don't think we want them to be. But we can use DW_AT_* constants as proxies--and we already know the one in question in this interface. So without even changing the API, we can make this call smart about use of DW_FORM_sec_offset. We just need some more internal knowledge about which attributes refer to which sections.
OK, so you don't want a low level interface that just gives you the offset as an index, but want an interface that explicitly ties it to a target section? Then using dwarf_formudata () would not be it. That is a pity though since that means you cannot do some things with an attribute depending on whether its value is encoded as a DW_FORM_data4/8 or DW_FORM_sec_offset. That was really why I just wanted the simple addition of DW_FORM_sec_offset decoding added to dwarf_formudata ().
Can't we have both? dwarf_formudata () for low-level access and a new dwarf_formsec_off() as a higher level api? The later in some future elfutils release after 0.138 of course.
As to the implementation, it can't use __libdw_read_address. It needs to be __libdw_read_offset or at least something using __libdw_relocate_offset. Otherwise it won't do the relocation handling the right way whenever we switch that stuff on.
Are you sure? For DW_FORM_data4/8 we already use __libdw_read_address. I might be missing something, but that seems correct because it uses the relocation handling hooks already. If that wasn't correct the previous workaround for reading DW_FORM_sec_offset by tweaking the Dwarf_Attribute form field (setting it to data4/8) was also incorrect. Is it?
address!=offset. This is all moot in the trunk, since they're both no-ops. But in the roland/relocate branch you'll see the difference. The kinds of relocs that are valid for an address are different from those for an offset.
I see, on the relocate branch the current usage of __libdw_read_address for DW_FORM_data4/8 is also wrong since it will do an additional check of whether the return value is within the data of the target section (which the current dwarf_formudata unconditionally sets to cu_sec_idx). So we will need more smarts, using the given Dwarf_Attribute, to make it work against the relocate branch. But do we need to do this now? Can't we for the 0.138 release just handle DW_FORM_sec_offset in dwarf_formudata () like we handle DW_FORM_data4/8? Then for a future release when we introduce a new high-level function and/or integrate the relocate branch we can fix it up for all forms.
Thanks,
Mark
OK, so you don't want a low level interface that just gives you the offset as an index, but want an interface that explicitly ties it to a target section? Then using dwarf_formudata () would not be it.
I didn't quite say that. I do think there are precious few good reasons for wanting to see such an offset as an integer. But if you are really writing something that is concerned with the lowest levels of encoding, then perhaps it is what you want. (For anything interesting, I think you really just want to look at the referenced information semantically.)
dwarf_formudata could be it. My suggestion was that it could handle it, with smarts to know which section it referred to so it can validate the offset (and handle relocation with pedantic correctness).
Can't we have both? dwarf_formudata () for low-level access and a new dwarf_formsec_off() as a higher level api? The later in some future elfutils release after 0.138 of course.
Get out of the Wayback Machine, Mark. We're talking about 0.153 now.
As I said before and just reiterated above, dwarf_formudata could be OK for the low-level access if we make it appropriately smart. I don't think it makes sense to consider anything about "sec_offset" to be "higher-level". The only things that are actually higher-level are interfaces that are about getting the information the attribute points to, not the encoding-level detail of a section offset. We already have such interfaces for the various kinds of things pointed to, and can add more at that level for whatever is missing.
I see, on the relocate branch the current usage of __libdw_read_address for DW_FORM_data4/8 is also wrong since it will do an additional check of whether the return value is within the data of the target section (which the current dwarf_formudata unconditionally sets to cu_sec_idx).
I think you are misunderstanding the meaning of the arguments to __libdw_read_address. The check against SEC_INDEX is verifying that the attribute data pointer is valid--that's always a pointer into the CU section. There are no checks on the value extracted.
So we will need more smarts, using the given Dwarf_Attribute, to make it work against the relocate branch. But do we need to do this now? Can't we for the 0.138 release just handle DW_FORM_sec_offset in dwarf_formudata () like we handle DW_FORM_data4/8? Then for a future release when we introduce a new high-level function and/or integrate the relocate branch we can fix it up for all forms.
I'd like to make it consistent now. The smarts will validate that it's an attribute expected to hold a section offset, and that the offset is valid for its target section.
Thanks, Roland
On Fri, Jan 27, 2012 at 09:45:32AM -0800, Roland McGrath wrote:
I'd like to make it consistent now. The smarts will validate that it's an attribute expected to hold a section offset, and that the offset is valid for its target section.
OK, I think I get what you mean now. How does the attached patch look?
It does mean we do a bit more sanity checking than before in dwarf_formudata. So is that not too invasive just before the release? Or should the new code be but in its own new function dwarf_formsec_offset to keep the new code separate?
Thanks,
Mark
OK, I think I get what you mean now. How does the attached patch look?
It does mean we do a bit more sanity checking than before in dwarf_formudata. So is that not too invasive just before the release? Or should the new code be but in its own new function dwarf_formsec_offset to keep the new code separate?
I guess my first inclination is that we only touch the DW_FORM_sec_offset case, but keep it in the existing API. That seems appropriately conservative, since it only touches a code path that was an error before. But your change as-is doesn't really bother me.
- Copyright (C) 2003-2010 Red Hat, Inc.
- Copyright (C) 2003-2010, 2012 Red Hat, Inc.
Just update the end of the range. (I think newer copyright.el handles this or has an option for it.)
/* Not one of the special attributes, just a constant. */
Two spaces at end.
/* We are dealing with an constant data4 or data8. */
s/an/a/
Thanks, Roland
On Tue, Jan 31, 2012 at 12:28:42PM -0800, Roland McGrath wrote:
I guess my first inclination is that we only touch the DW_FORM_sec_offset case, but keep it in the existing API. That seems appropriately conservative, since it only touches a code path that was an error before. But your change as-is doesn't really bother me.
OK, if it doesn't bother you, then it won't bother me. Pushed it with the fixes you suggested.
I am not sure we are making progress on the other (elflint) issue. It seems to me that at least Alan Modra doesn't feel it is an issue (see binutils list), but even though I disagree fixing it in binutils ld is a bit of a pain. I tried and didn't get a good fix (it also goes somewhat against the design in binutils ld that input sections and output sections are in theory separate) and Richard Henderson's fix has the disadvantage of turning all "missing" symbol sections into SHN_ABS, which also isn't ideal. So, should we add another ld-gnu quirk in elflint?
Cheers,
Mark
I am not sure we are making progress on the other (elflint) issue. It seems to me that at least Alan Modra doesn't feel it is an issue (see binutils list), but even though I disagree fixing it in binutils ld is a bit of a pain. I tried and didn't get a good fix (it also goes somewhat against the design in binutils ld that input sections and output sections are in theory separate) and Richard Henderson's fix has the disadvantage of turning all "missing" symbol sections into SHN_ABS, which also isn't ideal. So, should we add another ld-gnu quirk in elflint?
Alan is just clearly wrong about what should be acceptable. I'm not sure what is really wrong with Richard's fix. Can you give an example of a symbol it affects that is not wrong today?
Thanks, Roland
On Tue, 2012-01-31 at 15:20 -0800, Roland McGrath wrote:
I am not sure we are making progress on the other (elflint) issue. It seems to me that at least Alan Modra doesn't feel it is an issue (see binutils list), but even though I disagree fixing it in binutils ld is a bit of a pain. I tried and didn't get a good fix (it also goes somewhat against the design in binutils ld that input sections and output sections are in theory separate) and Richard Henderson's fix has the disadvantage of turning all "missing" symbol sections into SHN_ABS, which also isn't ideal. So, should we add another ld-gnu quirk in elflint?
Alan is just clearly wrong about what should be acceptable. I'm not sure what is really wrong with Richard's fix. Can you give an example of a symbol it affects that is not wrong today?
No, and I guess it is more compliant than what is done now. It is just that just turning those symbols into SHN_ABS basically gives up on them. That might be the best we can do with the current ld design though :{
It is correct in the sense that we have no better choice, but wrong in the sense that those symbol addresses really aren't "absolute".
But we should probably have this discussion on the binutils list if we want to get a change there.
Cheers,
Mark
No, and I guess it is more compliant than what is done now. It is just that just turning those symbols into SHN_ABS basically gives up on them. That might be the best we can do with the current ld design though :{
I'm not sure why you say that. They are symbols with names and addresses. In a linked object, the section assignment is really just some ancillary information and not intrinsically all that meaningful.
It is correct in the sense that we have no better choice, but wrong in the sense that those symbol addresses really aren't "absolute".
Unless I'm missing something, there are three sensible options. 1. A preserved symbol in a discarded section becomes SHN_ABS. 2. A discarded section is not actually discarded, but assigned to one of the adjacent output sections, so its symbols wind up in that section. 3. No orphan input section is discarded if it contains any symbols.
My impression is that gold just doesn't discard any sections at all, instead producing empty output sections. I don't see any harm in that.
Thanks, Roland
On Wed, Feb 01, 2012 at 10:22:35AM -0800, Roland McGrath wrote:
No, and I guess it is more compliant than what is done now. It is just that just turning those symbols into SHN_ABS basically gives up on them. That might be the best we can do with the current ld design though :{
I'm not sure why you say that. They are symbols with names and addresses. In a linked object, the section assignment is really just some ancillary information and not intrinsically all that meaningful.
But if you emit the information anyway then it is (as even Alan admits) useful for analysing tools. In this particular case knowing that a symbol/address came from the .tm_clone_table seems useful to me.
Unless I'm missing something, there are three sensible options.
- A preserved symbol in a discarded section becomes SHN_ABS.
- A discarded section is not actually discarded, but assigned to one of the adjacent output sections, so its symbols wind up in that section.
- No orphan input section is discarded if it contains any symbols.
There also is the option of just doing away with the section table and just keep the program headers when producing an executable of course. But that also isn't particularly useful.
My impression is that gold just doesn't discard any sections at all, instead producing empty output sections. I don't see any harm in that.
Yes, that (3) seems the best option. IMHO. Both 1 and 2 loose the original information. But we need to have this discussion on the binutils list if we want to advocate a change/patch for ld.
Cheers,
Mark
But if you emit the information anyway then it is (as even Alan admits) useful for analysing tools. In this particular case knowing that a symbol/address came from the .tm_clone_table seems useful to me.
Agreed.
Unless I'm missing something, there are three sensible options.
- A preserved symbol in a discarded section becomes SHN_ABS.
- A discarded section is not actually discarded, but assigned to one of the adjacent output sections, so its symbols wind up in that section.
- No orphan input section is discarded if it contains any symbols.
There also is the option of just doing away with the section table and just keep the program headers when producing an executable of course. But that also isn't particularly useful.
It's useful for some things, but only for things wherein you discard the entire symbol table, so this issue is moot.
My impression is that gold just doesn't discard any sections at all, instead producing empty output sections. I don't see any harm in that.
Yes, that (3) seems the best option. IMHO. Both 1 and 2 loose the original
^-o
information.
Agreed.
But we need to have this discussion on the binutils list if we want to advocate a change/patch for ld.
Feel free to CC me if you take it up there.
Thanks, Roland
On Wed, 2012-02-01 at 10:47 -0800, Roland McGrath wrote:
But we need to have this discussion on the binutils list if we want to advocate a change/patch for ld.
Feel free to CC me if you take it up there.
Without any pushing Alan Modra changed his mind and would allow Richard Henderson's patch to turn the "stray symbols" to ABS. So if that gets in then I think we don't have any (testresult) show stoppers anymore for the release.
Anything else that is needed before "blessing" 0.153?
Thanks,
Mark
I don't know of any other issues off hand. What I usually did for past releases was locally change the version number in configure.ac and do a 'make distcheck', then use that tarball for a Fedora srpm. Then send that srpm for scratch builds in all the live Fedora and RHEL builders. That shakes out things like new elflint complaints from tool changes on ppc or s390. When all that stuff comes up green, then there's probably nothing else to wait for.
Thanks, Roland
On Mon, 2012-02-13 at 10:48 -0800, Roland McGrath wrote:
I don't know of any other issues off hand. What I usually did for past releases was locally change the version number in configure.ac and do a 'make distcheck'
To get all the tests to PASS inside the make distcheck I need the following patch:
diff --git a/tests/Makefile.am b/tests/Makefile.am index 3074c89..82783c4 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -163,7 +163,7 @@ EXTRA_DIST = run-arextract.sh run-arsymtest.sh \ testfile55-64.debug.bz2 testfile55-64.prelink.bz2 \ testfile56.bz2 testfile57.bz2 testfile58.bz2
-installed_TESTS_ENVIRONMENT = libdir=$(DESTDIR)$(libdir) \ +installed_TESTS_ENVIRONMENT = libdir=$(DESTDIR)$(libdir):$(DESTDIR)$(libdir)/elfutils \ bindir=$(DESTDIR)$(bindir) \ $(srcdir)/test-wrapper.sh \ installed $(tests_rpath) \
Otherwise the tests won't find the libebl backends. Does that make sense or is there some other trick I am missing?
Thanks,
Mark
On Tue, Feb 21, 2012 at 11:14:52AM -0800, Roland McGrath wrote:
Otherwise the tests won't find the libebl backends. Does that make sense or is there some other trick I am missing?
It doesn't seem proper to set libdir to something other than libdir. I changed test-wrapper.sh instead. Please verify it works right.
It seems better to change test-wrapper.sh instead. Sadly the current change doesn't work fully. I also need the following change:
diff --git a/tests/test-subr.sh b/tests/test-subr.sh index cb34b93..f91f1cb 100644 --- a/tests/test-subr.sh +++ b/tests/test-subr.sh @@ -99,7 +99,7 @@ installed_testrun() ;; esac if [ "${libdir}" != /usr/lib ] && [ "${libdir}" != /usr/lib64 ]; then - LD_LIBRARY_PATH="${libdir}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" \ + LD_LIBRARY_PATH="${libdir}:${libdir}/elfutils${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" \ $program ${1+"$@"} else $program ${1+"$@"}
Does that look sane?
Thanks,
Mark
Done.
I don't think I mentioned these before, but the other items for the release checklist are to update the portable and robustify branches. i.e., merge master into each. (I've just done this.)
Then use the Fedora pkgs-git elfutils/Makefile to update the patch files for distribution. Use that elfutils-portability.patch in the srpm you send to Koji for scratch builds (before committing anything the pkgs git). I think what I did in the past was to send the portable-srpm to the RHEL[45] scratch builders (I'm not sure RHEL4 builds any more at all, and if it didn't last release then we don't care). Note that RHEL6 builders should handle the vanilla Fedora srpm fine.
Thanks, Roland
On Tue, 2012-02-21 at 12:58 -0800, Roland McGrath wrote:
I don't think I mentioned these before, but the other items for the release checklist are to update the portable and robustify branches. i.e., merge master into each. (I've just done this.)
Then use the Fedora pkgs-git elfutils/Makefile to update the patch files for distribution. Use that elfutils-portability.patch in the srpm you send to Koji for scratch builds (before committing anything the pkgs git).
ah, I didn't know that was all automated. nice. I had done that previously locally and generated the patches by hand.
I think what I did in the past was to send the portable-srpm to the RHEL[45] scratch builders (I'm not sure RHEL4 builds any more at all, and if it didn't last release then we don't care). Note that RHEL6 builders should handle the vanilla Fedora srpm fine.
The plain elfutils builds fine on all RHEL6 architectures, with all tests passing.
For RHEL5 I had to enable the new --disable-werror support in the portable branch patch to get a full build going. With that things build and all arches PASS all tests, except for one elflint failure on ia64 (section [ 2] '.dynsym': symbol 1: symbol in dynamic symbol table with non-default visibility). But this was there also in earlier versions so I am not too worried. Will look into it, but shouldn't be a release stopper.
I couldn't easily get a rpm build going on RHEL4 (the last official build on that platform was 0.97 from 2007). But I could build the portable branch by hand on x86_64. There is one failure from elflint (all other tests PASS) because the linker creates a .dynsym table where local and global symbols are mixed (and so sh_info doesn't point to the first STB_GLOBAL symbol). There is nothing we can do about that.
So I think we are good to go now.
Cheers,
Mark
Ok. I think you can cut it unless Uli really wants to. If --enable-maintainer-mode, then make distcheck ought to automagically update config/elfutils.spec.in. It looks like we haven't made a top-level ChangeLog entry for updating the version in configure.ac in the past.
Then commit and git tag -s elfutils-0.153 and push.
Then make distcheck again for good measure, and then gpg -b the tar.bz2 file and copy over tar.bz2{,.sig} to your pkgs-git checkout, update the patches and edit elfutils.spec there (be sure to include any Fedora bugzilla #s fixed there).
Hmm. I'm not sure if everyone can upload to fedorahosted.org. The documented way is "scp file... fedorahosted.org:elfutils". But we now make a directory (i.e. 0.153/) and put things under that. I don't know if that scp will create the directory for you, maybe it will if you use "scp -r 0.153 fedorahosted.org:elfutils". If not, I can create the directory (I have shell login access, not just scp). But why don't you try it, and find me on freenode if it didn't work.
It should get the tar.bz2, tar.bz2.sig, and two *.patch files.
Then there are the fedpkg steps, but I assume you know those.
I don't think I forgot anything, but it's been a long time now since I last did this.
Thanks, Roland
Hi Roland,
As you saw it all went perfectly, just a few comments in case someone else does it next time (or just as documentation for myself).
On Wed, Feb 22, 2012 at 10:34:11AM -0800, Roland McGrath wrote:
Ok. I think you can cut it unless Uli really wants to. If --enable-maintainer-mode, then make distcheck ought to automagically update config/elfutils.spec.in.
Make sure you update the configure.ac version and copyright year. Double check the email address put in elfutils.spec.in, the Makefile logic is a little too simplistic but changing it more intelligently is more work than just checking the diff generated afterwards.
It looks like we haven't made a top-level ChangeLog entry for updating the version in configure.ac in the past.
I added them this time.
Then commit and git tag -s elfutils-0.153 and push.
Then merge master into the portable and robustify branches one last time.
Then make distcheck again for good measure, and then gpg -b the tar.bz2 file and copy over tar.bz2{,.sig} to your pkgs-git checkout, update the patches and edit elfutils.spec there (be sure to include any Fedora bugzilla #s fixed there).
You update the patches by removing them and typing make elfutils-portability.patch elfutils-robustify.patch Don't forget to update the Makefile elfutils.git ?= rule if you have the local git checkout somewhere else.
And don't forget to strip out old patches that have been incorporated in the new release. Forgot that myself at first. Causing some confusion.
Hmm. I'm not sure if everyone can upload to fedorahosted.org. The documented way is "scp file... fedorahosted.org:elfutils". But we now make a directory (i.e. 0.153/) and put things under that. I don't know if that scp will create the directory for you, maybe it will if you use "scp -r 0.153 fedorahosted.org:elfutils".
That worked fine.
If not, I can create the directory (I have shell login access, not just scp). But why don't you try it, and find me on freenode if it didn't work.
BTW. There is now a #elfutil channel on freenode.
It should get the tar.bz2, tar.bz2.sig, and two *.patch files.
Then there are the fedpkg steps, but I assume you know those.
fedpkg new-sources elfutils-0.153.tar.bz2 git commit -a -m "Update to 0.153" fedpkg local [If you want to check things out locally first] fedpkg build [To trigger a koji build] (git checkout f<old>; git merge master; etc. as appropriate) (Have to use fedpkg update on anything not rawhide to trigger bodhi)
Note, f17 didn't yet get the fixed binutils, it is still in some update bodhi cycle, so the build there failed, will resubmit when binutils in f17 gets through.
Afterwards I saw that with a newer autotools you will get warnings in the portable configure.ac for not using AC_LANG_SOURCE inside AC_COMPILE_IFELSE. Fixed that on the branch.
Also rpmlint caused errors for the outdated COPYING file (which contains a bad address). I updated it with a fresh one from gnulib.
Cheers,
Mark
Then commit and git tag -s elfutils-0.153 and push.
One last question. I don't see the tag appear remotely. And if I do a fresh clone it also isn't there. But locally I can do:
$ git tag -v elfutils-0.153 object 62f4c7bc236015c168c692776551b7dcf50fff66 type commit tag elfutils-0.153 tagger Mark J. Wielaard mjw@redhat.com 1329996903 +0100
Prepare 0.153 release. gpg: Signature made Thu 23 Feb 2012 12:35:14 PM CET using RSA key ID 57816A6A gpg: Good signature from "Mark J. Wielaard mark@klomp.org" gpg: aka "Mark J. Wielaard mjw@gnu.org" gpg: aka "Mark J. Wielaard mjw@redhat.com"
How to push this tag?
Thanks,
Mark
On Fri, 2012-02-24 at 11:23 +0100, Mark Wielaard wrote:
Then commit and git tag -s elfutils-0.153 and push.
One last question. I don't see the tag appear remotely. [...] How to push this tag?
As fche pointed out on irc you have to push tags separately: $ git push --tags done!
On Tue, 2012-02-21 at 21:43 +0100, Mark Wielaard wrote:
On Tue, Feb 21, 2012 at 11:14:52AM -0800, Roland McGrath wrote:
Otherwise the tests won't find the libebl backends. Does that make sense or is there some other trick I am missing?
It doesn't seem proper to set libdir to something other than libdir. I changed test-wrapper.sh instead. Please verify it works right.
It seems better to change test-wrapper.sh instead. Sadly the current change doesn't work fully. I also need the following change:
diff --git a/tests/test-subr.sh b/tests/test-subr.sh index cb34b93..f91f1cb 100644 --- a/tests/test-subr.sh +++ b/tests/test-subr.sh @@ -99,7 +99,7 @@ installed_testrun() ;; esac if [ "${libdir}" != /usr/lib ] && [ "${libdir}" != /usr/lib64 ]; then
- LD_LIBRARY_PATH="${libdir}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" \
- LD_LIBRARY_PATH="${libdir}:${libdir}/elfutils${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" \ $program ${1+"$@"} else $program ${1+"$@"}
Does that look sane?
I see you added a similar change to git master. With that make distcheck works out of the box for me (if setting the version to 0.153 in configure.ac).
Thanks,
Mark
On Mon, 2012-02-13 at 10:48 -0800, Roland McGrath wrote:
I don't know of any other issues off hand. What I usually did for past releases was locally change the version number in configure.ac and do a 'make distcheck', then use that tarball for a Fedora srpm. Then send that srpm for scratch builds in all the live Fedora and RHEL builders. That shakes out things like new elflint complaints from tool changes on ppc or s390. When all that stuff comes up green, then there's probably nothing else to wait for.
That is a nice trick. Nick Clifton was nice enough to push Richard Henderson's fix into the fedora binutils package and I did the above koji scratch builds for x86-rawhide, x86_64-rawhide, armv5tel-f17, armv7hl-f17, ppc-rawhide, ppc64-rawhide, s390-f17 and s390x-f17, all came up green, all tests PASS, except for the s390x-f17 one which did have the newer gcc 4.7-prerelease but not yet the fixed binutils (only the symtab symbol st_value out of bounds check failed, which is expected in that case). So I think we are good to go (depending on whether or not that make distcheck test fail thingy is a real issue or not).
Cheers,
Mark
(Frankly IMHO it's a no-brainer that when DWARF introduced DW_FORM_sec_offset they should have added the ten distinct forms for the different target sections, it's not like we're really in danger of running out of form codes. But they didn't ask me.)
We did consider that. But form codes are the one thing in DWARF that you can't extend without breaking existing consumers -- you can skip over unknown attributes and even unknown tags as long as you know all the form codes involved, but once you see a form code you don't know, you can't continue parsing the debug info at all. Therefore, we thought it would set a bad precedent to encourage the creation of a new form code for each new section you might want to point to from an attribute.
The idea that the attribute itself implies the section you're referring to was recognized to be a disadvantage to generic DWARF utilities, but we figured that any such utility would either (a) recognize the attribute and thus know which section is implied, or (b) treat the offset as a general section offset. In the latter case, you might lose some useful output (e.g., in readelf), or some error checking (e.g., a dwarflint-like tool), but the tool would still be able to operate on the file. The alternative is that the tool might see a form code it doesn't recognize and not be able to operate on the file at all.
-cary
elfutils-devel@lists.fedorahosted.org
-
Cary Coutant -
Josh Stone -
Mark Wielaard -
Mark Wielaard -
Roland McGrath -
Ulrich Drepper