https://sourceware.org/bugzilla/show_bug.cgi?id=32540
--- Comment #4 from Mark Wielaard <mark at klomp dot org> ---
Hi Michael,
(In reply to Michael Tremer from comment #2)
> I did notice the string function, but how would I programmatically check
> what kind of error was returned? String matching does not sound like a safe
> option.
You wouldn't programmatically check because an error is just an error, the
human readable error string is just a hint for the user to display.
> My code looks like this:
>
> > // Read DWARF information
> > dwarf = dwarf_begin(self->fd, DWARF_C_READ);
> > if (!dwarf) {
> > switch (dwarf_errno()) {
> > // If we don't have any DWARF information there is
> > nothing to do
> > case DWARF_E_NO_DWARF:
> > r = 0;
> > goto ERROR;
> >
> > default:
> > ERROR(self->ctx, "Could not initialize DWARF
> > context: %s\n", dwarf_errmsg(-1));
> > r = -errno;
> > goto ERROR;
> > }
> > }
>
> I am basically trying to extract any source information before I am
> stripping the binary. Sometimes there is no DWARF information. From the NULL
> pointer that is being returned by dward_begin() I cannot tell whether there
> has been an error, or genuinely no DWARF information was found - which in my
> case is an acceptable outcome.
There can be many errors, not having (all) .debug_* sections is just one of the
reasons for not having DWARF information. It could also be there, but not in a
format or version libdw supports (yet) for example.
> A bit further into my routine I have a similar case:
>
> > // Fetch the source files
> > r = dwarf_getsrcfiles(die, &files, &count);
> > if (r < 0) {
> > switch (dwarf_errno()) {
> > // Skip any invalid DWARF sections
> > case DWARF_E_INVALID_DWARF:
> > goto NEXT;
> >
> > default:
> > ERROR(self->ctx, "Could not fetch the
> > source files for %s: %s\n",
> > self->path, dwarf_errmsg(-1));
> > r = -ENOTSUP;
> > goto ERROR;
> > }
> > }
>
> Some files, if I remember correctly glibc start files, can get opened, but
> there seem to be some sections that cannot be parsed. As extracting the
> source is best-effort anyways, I would like to skip them and the error code
> allows me to.
I am not sure I understand why you are treating that specific error type
special. Why aren't you trying to move to the next CU for other errors?
P.S. I would certainly be interested in specific cases where there is an error
for some, but not all, dwarf DIE CUs getsrcfiles returns errors. Wondering
whether this might be ET_REL (object) files not having relocations applied.
> My full code is here:
> https://git.ipfire.org/?p=pakfire.git;a=blob;f=src/pakfire/elf.c;
> hb=ec4278ae949bcd5a73e47448afe404d187d89be2#l1127
>
> As a workaround I have been defining the two codes that I am currently
> using, but of course that won't be a stable solution for the future.
>
> I hope I could explain my use case a little bit more and there is a chance
> to export those error codes.
I don't think you can really distinguish error codes atm. They just indicate
something went wrong, but not exactly what. So for your program you shouldn't
really take different actions on errors based on the error code set.
--
You are receiving this mail because:
You are on the CC list for the bug.
