The attached new 0002*patch file has ChangeLog files and uses MAX to
replace union types. Please take a look again.
Thanks.
On Tue, Sep 8, 2015 at 2:15 PM, Roland McGrath wrote:
> That looks generally OK, though it lacks ChangeLog entries.
> But I think it's a bit weird to declare those union t
The 4 split patches looked good to me.
About the init value of enctype in tests/varlocs.c, yes,
clang does not seem to know that error(EXIT_FAILURE, ...) won't return.
Yes, the labs should be llabs to work on 32-bit systems.
About removing the NULL tests of parameters declared with NN,
I don't m
I think there might be circumstances when you can't open /proc/PID/exe.
I'm not sure you want failure to open it or it failing to be a readable
ELF file to be hard failures.
dwfl_linux_proc_attach depended on a DwflModule with the correct
ELF header already being available. That isn't really necessary since
when we attach we have the main exe ELF file available. Just use that
to make dwfl_linux_proc_attach always work.
Signed-off-by: Mark Wielaard
---
libdwfl/Change
That looks generally OK, though it lacks ChangeLog entries.
But I think it's a bit weird to declare those union types for
the sole purpose of using sizeof on them. I think it would
be cleaner to replace e.g. sizeof (phdr_u) with:
#define PHDR_MAX_SIZE MAX (sizeof (Elf32_Phdr), sizeof (Elf64_Phdr)
I have replaced this patch with a new one that does not use one element
arrays.
Please take a look of
[PATCH] Do without union of variable length arrays.
Thanks.
On Fri, Sep 4, 2015 at 3:14 PM, Roland McGrath wrote:
> > Is there some simple way that I can test elfutils with fortify or bound
Prepare to compile without gnu99 extension.
A union like
{ T32 a32[n]; T64 a64[n]; } u;
is expanded to
void *data = malloc (...);
T32 *a32 = data;
T64 *a64 = data;
Signed-off-by: Chih-Hung Hsieh
---
libdwfl/dwfl_module_getdwarf.c | 46 +++-
libdwfl/dwfl_segment_rep
Hi Ben,
On Mon, 2015-09-07 at 15:24 +0200, Ben Gamari wrote:
> > There is dl_iterate_phdr which is a GNU extensions, but some other
> > systems have something similar.
> >
> Right, I actually went ahead and implemented your suggestion after
> stumbling upon this in the manpages.
> [...]
> > Althou