Hi,
It has been 2 months since 0.154 and there have been 30+ commits since then, covering some new features and some important bug fixes. I think it is time for a new 0.155 release. Fedora is already carrying several backports and it would be good to get the fixes more widely adopted. So I am hoping to do a 0.155 release end of this week/this weekend.
There are some patches being reviewed at the moment. Lets see if we can integrate them by Friday. I am hoping the Tilera TILE-Gx, dwarfstrings functions and the strip on MIPS patches can be still make it. But if not, then we just do a new release in 2 months again. With the current change rate it seems appropriate that we do releases early and often so people know their contributions will be in a release soon.
I just updated the NEWS file to mention the changes since 0.154. It currently reads:
Version 0.155
libelf: elf*_xlatetomd now works for cross-endian elf note data. elf_getshdr now works consistently on non-mmaped ELF files after calling elf_cntl(ELF_C_FDREAD). Implement support for ar archives with 64-bit symbol table.
libdw: dwarf.h corrected the DW_LANG_ObjC constant name (was DW_LANG_Objc). Any existing sources using the old name will have to be updated. Add DW_MACRO_GNU .debug_macro type encodings constants, DW_ATE_UTF and DW_OP_GNU_parameter_ref to dwarf.h. Support for DWZ multifile forms DW_FORM_GNU_ref_alt/strp_alt.
readelf: Add .debug_macro parsing support. Add .gdb_index version 7 parsing support. Recognize DW_OP_GNU_parameter_ref.
Please mention anything I might have forgotten or improvements to the descriptions.
Thanks,
Mark
I don't want to rush on any API/ABI additions. Also note I will be out and incommunicado from this Friday through September 5th. So if you want a release soon (which I think is a fine thing), we should just tie up the pure fixes and backend additions this week and let more additions wait for the next release.
libelf: elf*_xlatetomd now works for cross-endian elf note data.
Upcase ELF.
elf_getshdr now works consistently on non-mmaped ELF files after calling elf_cntl(ELF_C_FDREAD).
This is just a bug fix and I don't think it needs to be described this way.
Support for DWZ multifile forms DW_FORM_GNU_ref_alt/strp_alt.
This is a problematic addition that opens new security issues in the tools. Since DWZ is not yet in wide use, if we want to make a release soon perhaps we should disable some of this support. It's also an extreme API layering violation. Doing this in a responsible way needs much more thought, so I think the only right thing to do for an imminent release is to disable the libdw support entirely.
Thanks, Roland
Hi -
On Tue, Aug 21, 2012 at 01:44:34PM -0700, Roland McGrath wrote:
[...]
Support for DWZ multifile forms DW_FORM_GNU_ref_alt/strp_alt.
This is a problematic addition that opens new security issues in the tools. [...]
Please elaborate.
Doing this in a responsible way needs much more thought, so I think the only right thing to do for an imminent release is to disable the libdw support entirely.
Mark has posted the dwz patches almost two months ago. It would be better to make progress toward responsible much more thought than to vaguely hold it up.
- FChE
This is a problematic addition that opens new security issues in the tools. [...]
Please elaborate.
They now open files whose names are controlled by the contents of input files.
Mark has posted the dwz patches almost two months ago.
I lost track and forgot about them until recently.
It would be better to make progress toward responsible much more thought than to vaguely hold it up.
There isn't time to resolve it before I leave at the end of this week. We can make progress on this subject when I've returned, but I think Mark wants to get a release going before then. Please don't start discussing the details now and expect that I will respond or that you can draw conclusions without my input. I don't have time to discuss it this week.
Thanks, Roland
On Tue, Aug 21, 2012 at 01:44:34PM -0700, Roland McGrath wrote:
I don't want to rush on any API/ABI additions. Also note I will be out and incommunicado from this Friday through September 5th. So if you want a release soon (which I think is a fine thing), we should just tie up the pure fixes and backend additions this week and let more additions wait for the next release.
That is fine. Anything we won't get in this week will get in the next release in 2 months.
libelf: elf*_xlatetomd now works for cross-endian elf note data.
Upcase ELF.
Changed.
elf_getshdr now works consistently on non-mmaped ELF files after calling elf_cntl(ELF_C_FDREAD).
This is just a bug fix and I don't think it needs to be described this way.
Suggestions for a better description welcome. Originally I had: "elf_getshdr now doesn't sometimes assert on non-mmaped ELF files after calling elf_cntl(ELF_C_FDREAD)."
Support for DWZ multifile forms DW_FORM_GNU_ref_alt/strp_alt.
This is a problematic addition that opens new security issues in the tools. Since DWZ is not yet in wide use, if we want to make a release soon perhaps we should disable some of this support. It's also an extreme API layering violation. Doing this in a responsible way needs much more thought, so I think the only right thing to do for an imminent release is to disable the libdw support entirely.
It will be fine. The alt files are only parsed when the user has control over the to open file contents in the first place. But I will ask the GDB hackers if they saw any issues. The alt_ref support isn't some last minute feature that didn't see any design or testing. I did consult with Jakub to make sure I understood all details of the spec and the dwz implementation. I coordinated with Tom to make sure GDB and elfutils interpreted them the same way. Tom was also nice enough to review the initial patch. The initial patch was posted publicly 2 months ago. We discussed in in person at the Cauldron. Based on that I posted a version that didn't have any api changes one month ago so everything is just implementation details we can still change. It was tested in fedora rawhide during the rebuild that created dwz files for all debuginfo packages. And I made sure that stap works smoothly with it. Only after all that it was committed begin of this month. It might be we missed some issues, but that will just be bugs we will eventually find and fix for a next release.
Cheers,
Mark
Suggestions for a better description welcome. Originally I had: "elf_getshdr now doesn't sometimes assert on non-mmaped ELF files after calling elf_cntl(ELF_C_FDREAD)."
We haven't usually added NEWS items for bug fixes.
It will be fine. [...]
No, it won't. You are missing the security issues I'm talking about. (It's also completely wrong API layering.) Sorry I gave you a false impression of approval about this. I was not thinking very clearly at the Cauldron. I object strenuously to making a release with this code in it. We can discuss the details when I'm back from vacation.
Thanks, Roland
On Thu, 2012-08-23 at 13:57 -0700, Roland McGrath wrote:
Suggestions for a better description welcome. Originally I had: "elf_getshdr now doesn't sometimes assert on non-mmaped ELF files after calling elf_cntl(ELF_C_FDREAD)."
We haven't usually added NEWS items for bug fixes.
But this was a particularly nasty and confusing one, so I do want to mention it explicitly so people who stumbled over it will notice.
It will be fine. [...]
No, it won't. You are missing the security issues I'm talking about.
Again, you give no specifics, and you are snipping my response why it isn't one. I did think about it. Also like I said I would, I asked others with dwz experience to take a look and they also didn't know what you are implying. You make it really hard to help you fix issues.
(It's also completely wrong API layering.) Sorry I gave you a false impression of approval about this. I was not thinking very clearly at the Cauldron.
:) You were the one suggesting it was better to not have public interfaces and keep the implementation details hidden and let libdw/libdwfl directly interface if necessary. I do agree with that. And as the patch history shows that is how we did it in the end. I am interested in your improvements of course. But I have not seen them.
I object strenuously to making a release with this code in it. We can discuss the details when I'm back from vacation.
If you feel so strongly about it then I can certainly disable it by default. But you are not being very helpful. You cannot just ignore discussions about patches for months and just handwave about issues which you then fail to be specific about or even offer alternatives for. Hope your vacation is refreshing and we will have a bit more productive cooperation afterwards.
Cheers,
Mark
elfutils-devel@lists.fedorahosted.org