On Fri, Jun 6, 2025 at 8:49 AM Mark Wielaard <m...@klomp.org> wrote: > > Hi Aaron, > > On Thu, 2025-06-05 at 17:12 -0400, Aaron Merey wrote: > > Signed-off-by: Aaron Merey <ame...@redhat.com> > > --- > > > > v2: Address Mark's suggestions > > https://patchwork.sourceware.org/project/elfutils/patch/20250603012245.411580-1-ame...@redhat.com/ > > It does indeed. Thanks. > > Just one nitpick, feel free to ignore, or resolve and just push the > result. > > > +.TP > > +\fIref\fP > > +A reference to an existing \fBElf\fP descriptor. If not NULL, this will be > > +used to duplicate a previous ELF descriptor. The reference count > > associated > > +with \fIref\fP will be incremented and \fBelf_end(3)\fP will need to be > > called > > +an additional time to deallocate \fIref\fP. \fIref\fP must have been > > opened > > +with read/write permissions consistent with \fIcmd\fP. If \fIref\fP is an > > AR > > +file, then the ELF descriptor returned will be the first available object > > member > > +of the archive (see \fBelf_next(3)\fP for more information). > > Could we somehow break this more clearly between a ref being a > "regular" ELF file and an AR file? Because elf_begin acts totally > different between the two. Maybe split the above in two paragraphs? > Also you mention elf_next here, but not ... > > > +.SH SEE ALSO > > +.BR mmap (2), > > +.BR elf_clone (3), > > +.BR elf_end (3), > > +.BR elf_rand (3), > > +.BR libelf (3), > > +.BR elf (5) > > ... here.
Thanks Mark, I added elf_next here and split the description of ref into a couple paragraphs to clarify AR vs non-AR behavior. Aaron
