Re: Post-1.1.1 plans

[Rich Felker <dalias@libc.org>]

On Wed, May 21, 2014 at 09:15:42AM +0300, Timo Teras wrote:
> On Tue, 20 May 2014 18:33:25 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > A few things I want to work on either adding or making decisions
> > about, aside from the existing roadmap items:
> > 
> > - Stuff left in the "Open issues at end of April" thread:
> >   - Renaming _start in dynamic linker (annoying for debugging)
> >   - Resolving max_align_t issue and adding it
> >   - Pending __xmknod and __sysv_signal patch (ABI compat)
> >   - Pending fmtmsg patch (probably ok as-is)
> >   - Adding recvmmsg/sendmmsg (waiting on Timo, I think)
> 
> I don't really have a good idea on how to do it nicely. Perhaps try to
> fix kernel on 64-bits?

Repeatedly calling sendmsg does not work because timeout can't be
honored, but repeatedly calling sendmmsg with a count of 1 seems
viable (and likewise for recvmmsg but I don't remember if it's as
difficult or not; need to look back at archives).

As for the const issue, glibc seems to have resolved to remove it. I
think we can do the same but perhaps we should document (when we do)
that the contents of the timespec after return are unspecified.

> >   - The if_nameindex/getifaddrs issue
> > - LINE_MAX vs sysconf(_SC_LINE_MAX) issue
> > - Proposed errc/etc. addition to err.h
> > - And error.h?
> > - Whether to add default timezone from /etc?
> 
> We just default to ":localtime" if TZ is not defined:
> http://git.alpinelinux.org/cgit/aports/plain/main/musl/2001-default-to-localtime-timezone-if-TZ-is-undefined.patch
> 
> and we make /etc/zoneinfo/localtime a symlink to (or a copy of) the
> wanted timezone. Works perfect.

Yes, that probably works fine, but it may be desirable to have more
out-of-the-box compatibility with the way glibc does it for running
binaries on non-musl-based systems. (Not decided on this; just think
some people might prefer it.)

> > - reallocarray and explicit_bzero request
> > 
> > There may be other open things I'm missing; let me know if you have a
> > request that doesn't appear above.
> 
> Proper backtrace from core dumps of dynamic linked apps. At least to
> get analyzing core dumps working. I think adding CFI is 90% of this.
> But IIRC, gdb does not reliably detect mappings of shared objects. That
> might need something additional.

Do you have details on that?

> thread_db support would be also nice, but that falls into gdbing
> running processes.

Have you seen the one-line patch to gdb that seems to make everything
work fine without it?

Rich