Re: Preparing for elfutils 0.161 - Dec 12/15

Re: Preparing for elfutils 0.161 - Dec 12/15

[Vicente Olivert Riera]

[-- Attachment #1: Type: text/plain, Size: 4118 bytes --]

Dear Mark Wielaard,

On 12/02/2014 10:40 AM, Mark Wielaard wrote:
> Hi Hackers,
> 
> It is December already. Which means it has been more than 3 months since
> the last elfutils 0.160 release. We have had lots of bugfixes and some
> new features. So lets see if we are ready for 0.161. My goal is to
> release elfutils 0.161 around Friday 12 December/Monday 15 December.
> 
> Please try to aim to have anything you really want into elfutils 0.161
> in before Friday 12 December. Then we can run tests during the weekend
> and if everything looks fine we push out a shiny new release on Monday
> 15 December. Don't worry too much if something won't make the deadline.
> We'll do a new release after ~3 months again.
> 
> Some stuff I know people (some CCed) are still working on:
> 
> - More robustify fallout from running american fuzzy lop (afl-fuzz).
>   Most patches I intent to merge have been posted and are still on
>   mjw/pending. A couple more will probably show up before release once I
>   have analyzed some more crashers. The biggest outstanding issue is
>   "unbounded" (actually up to 10 bytes) s/uleb128 reading. I hope to get
>   support in for length checking when necessary. But this will need some
>   careful testing because this code is pretty performance critical.
>   Hanno, if you have any additional results please let us know. I don't
>   think we can promise elfutils to be fully robust in the face of
>   deliberately corrupted ELF/DWARF files with 0.161, but we will
>   certainly be a lot better. I have had afl-fuzz running for some days
>   now and it now takes hours for new crashers to show up.
> - I have been working on some GCC DWARF extensions based on the DWARFv5
>   draft. This will be experimental for GCC5, but would be nice to
>   support in elfutils, so people can at least test a little. I suspect
>   atomic types and alignment attributes might still make it. But this
>   isn't too important/critical and depends on GCC accepting the patches
>   first.
> - I had been looking at MIPS backend support and Kurt even got me access
>   to a Debian setup. But I haven't found the time and I am not sure I
>   can make the time before release. So this might have to move to 0.162.
>   Sorry.
> - Jose said he had some patches/cleanups for the sparc backend which
>   would be nice to integrate. But they haven't been posted yet. If you
>   post them I promise to review them ASAP. The only problem will be
>   testing since there are not many GNU/Linux Sparc machines around.
> - For .debug_macro support we still need to finish up the handling of
>   0xff. The DWARF committee decided they will allow 0xff as user defined
>   opcode, so we have to act accordingly. I believe Petr already knows
>   how to properly do this.
>   http://dwarfstd.org/ShowIssue.php?issue=141001.1
> - We discussed some flaws in eu-addr2line recently. Josh has some
>   patches and even more ideas. Lets get at least the bug fix in. We can
>   deal with "proper" inline frame handling later if we don't make it for
>   next Friday.
> - We also discussed transparent imports of partial units, but I think
>   there isn't any patches yet. So lets postpone that to next year.
> - Jan has some patches for making eu-stack usable as linux kernel
>   core_pattern handler. Which seem to be generically usable to monitor
>   exiting processes with eu-stack. But we still need to discuss how far
>   we want to go with that before committing to an interface/command line
>   (or maybe just document how the libdwfl interfaces can be used as
>    such?).
> 
> Did I forget anything? Please post patches early and often before next
> Friday so we know what can still make it into 0.161 and what will be
> done next year.
> 
> Cheers,
> 
> Mark
> 

I have one request for you. When you release the new 0.161, could you
please also add a version number to the portability patch?

Thanks.
-- 
Vicente Olivert Riera
Graduate Software Engineer, MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com

Re: Preparing for elfutils 0.161 - Dec 12/15

[Vicente Olivert Riera]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On 12/02/2014 11:57 AM, Mark Wielaard wrote:
> On Tue, 2014-12-02 at 10:43 +0000, Vicente Olivert Riera wrote:
>> I have one request for you. When you release the new 0.161, could you
>> please also add a version number to the portability patch?
> 
> Sure I can do that. Thanks for the suggestion. Note that each version
> has its own directory on the download site, which already contains the
> version number. Just not the file itself yet.
> https://fedorahosted.org/releases/e/l/elfutils/
> 
> BTW. What are you using the portability.patch for? It really should only
> contain workaround for bugs in older linux kernels or glibc versions.
> Applying it will probably make your version less efficient than plain
> elfutils. I hope to eventually get rid of it.

We use it in Buildroot (http://buildroot.org/). When the build system
tries to download a file called "elfutils-portability.patch", it can be
confusing because it can be already downloaded (a previous version) or
present in some mirror (a previous version as well), so when we upgrade
the elfutils version it may fail because it's trying to apply the old
patch. Well..., actually it fails the hash check :P

-- 
Vicente Olivert Riera
Graduate Software Engineer, MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com

Re: Preparing for elfutils 0.161 - Dec 12/15

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Tue, 2014-12-02 at 10:43 +0000, Vicente Olivert Riera wrote:
> I have one request for you. When you release the new 0.161, could you
> please also add a version number to the portability patch?

Sure I can do that. Thanks for the suggestion. Note that each version
has its own directory on the download site, which already contains the
version number. Just not the file itself yet.
https://fedorahosted.org/releases/e/l/elfutils/

BTW. What are you using the portability.patch for? It really should only
contain workaround for bugs in older linux kernels or glibc versions.
Applying it will probably make your version less efficient than plain
elfutils. I hope to eventually get rid of it.

Cheers,

Mark

Preparing for elfutils 0.161 - Dec 12/15

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]

Hi Hackers,

It is December already. Which means it has been more than 3 months since
the last elfutils 0.160 release. We have had lots of bugfixes and some
new features. So lets see if we are ready for 0.161. My goal is to
release elfutils 0.161 around Friday 12 December/Monday 15 December.

Please try to aim to have anything you really want into elfutils 0.161
in before Friday 12 December. Then we can run tests during the weekend
and if everything looks fine we push out a shiny new release on Monday
15 December. Don't worry too much if something won't make the deadline.
We'll do a new release after ~3 months again.

Some stuff I know people (some CCed) are still working on:

- More robustify fallout from running american fuzzy lop (afl-fuzz).
  Most patches I intent to merge have been posted and are still on
  mjw/pending. A couple more will probably show up before release once I
  have analyzed some more crashers. The biggest outstanding issue is
  "unbounded" (actually up to 10 bytes) s/uleb128 reading. I hope to get
  support in for length checking when necessary. But this will need some
  careful testing because this code is pretty performance critical.
  Hanno, if you have any additional results please let us know. I don't
  think we can promise elfutils to be fully robust in the face of
  deliberately corrupted ELF/DWARF files with 0.161, but we will
  certainly be a lot better. I have had afl-fuzz running for some days
  now and it now takes hours for new crashers to show up.
- I have been working on some GCC DWARF extensions based on the DWARFv5
  draft. This will be experimental for GCC5, but would be nice to
  support in elfutils, so people can at least test a little. I suspect
  atomic types and alignment attributes might still make it. But this
  isn't too important/critical and depends on GCC accepting the patches
  first.
- I had been looking at MIPS backend support and Kurt even got me access
  to a Debian setup. But I haven't found the time and I am not sure I
  can make the time before release. So this might have to move to 0.162.
  Sorry.
- Jose said he had some patches/cleanups for the sparc backend which
  would be nice to integrate. But they haven't been posted yet. If you
  post them I promise to review them ASAP. The only problem will be
  testing since there are not many GNU/Linux Sparc machines around.
- For .debug_macro support we still need to finish up the handling of
  0xff. The DWARF committee decided they will allow 0xff as user defined
  opcode, so we have to act accordingly. I believe Petr already knows
  how to properly do this.
  http://dwarfstd.org/ShowIssue.php?issue=141001.1
- We discussed some flaws in eu-addr2line recently. Josh has some
  patches and even more ideas. Lets get at least the bug fix in. We can
  deal with "proper" inline frame handling later if we don't make it for
  next Friday.
- We also discussed transparent imports of partial units, but I think
  there isn't any patches yet. So lets postpone that to next year.
- Jan has some patches for making eu-stack usable as linux kernel
  core_pattern handler. Which seem to be generically usable to monitor
  exiting processes with eu-stack. But we still need to discuss how far
  we want to go with that before committing to an interface/command line
  (or maybe just document how the libdwfl interfaces can be used as
   such?).

Did I forget anything? Please post patches early and often before next
Friday so we know what can still make it into 0.161 and what will be
done next year.

Cheers,

Mark