diff mbox

[RFC] Make libbacktrace more standalone

Message ID alpine.LNX.2.00.1305202041450.26719@monopod.intra.ispras.ru
State New
Headers show

Commit Message

Alexander Monakov May 20, 2013, 5:07 p.m. UTC 
I now realize that a less intrusive approach is available: just provide
replacement filenames.h, dwarf2.h in a separate directory and pick up those
headers for a standalone build.  In replacement dwarf2.h, include system
dwarf.h, #define potentially missing enum values and provide dummy enum tags.
The downside is that GCC complains about using variables of dummy enum types
in comparisons and switch statements, necessitating -Wno-switch and
-Wno-enum-compare.

Build system dependencies are a bigger problem that is beyond "scratching my
own itch" at the moment (I have to provide a CMake build script anyhow).

The below is what I submitted to import libbacktrace in the APITrace project.
I'm not sure whether it makes sense to commit it in GCC: it's not particularly
useful without the standalone CMake build script.

Alexander

Comments

Ian Lance Taylor May 20, 2013, 5:30 p.m. UTC | #1 
On Mon, May 20, 2013 at 10:07 AM, Alexander Monakov <amonakov@ispras.ru> wrote:
> I now realize that a less intrusive approach is available: just provide
> replacement filenames.h, dwarf2.h in a separate directory and pick up those
> headers for a standalone build.  In replacement dwarf2.h, include system
> dwarf.h, #define potentially missing enum values and provide dummy enum tags.
> The downside is that GCC complains about using variables of dummy enum types
> in comparisons and switch statements, necessitating -Wno-switch and
> -Wno-enum-compare.
>
> Build system dependencies are a bigger problem that is beyond "scratching my
> own itch" at the moment (I have to provide a CMake build script anyhow).
>
> The below is what I submitted to import libbacktrace in the APITrace project.
> I'm not sure whether it makes sense to commit it in GCC: it's not particularly
> useful without the standalone CMake build script.

To be clear: are you withdrawing your earlier patch?

I agree that your proposal seems like a reasonable approach, and I
agree that it doesn't need to be in GCC.  It could be in a standalone
copy of libbacktrace if anybody creates one.

Ian
Alexander Monakov May 21, 2013, 4:52 p.m. UTC | #2 
On Mon, 20 May 2013, Ian Lance Taylor wrote:

> To be clear: are you withdrawing your earlier patch?

Yes; at this point I don't think it improves anything sufficiently to spend
more time on it.

Forgive me a digression, but having now actually used libbacktrace, I have
the following questions.

1. The documentation does not say whether reusing "state" objects is allowed.
For instance, I'm using backtrace_simple, and then in the callback I'm
invoking dladdr and backtrace_pcinfo to gather file-line info if available.
Looks like at the moment it's fine, as no frame-specific information is stored
there.

2. The reason I'm invoking dladdr instead of backtrace_syminfo is the need to
obtain the name of the module containing the symbol.  Is that intended?
(IOW, would be nice if libbacktrace syminfo callback provided name and base
address of the loaded module as well)

3. In libbacktrace/elf.c, elf_syminfo() does not seem to walk the chain of
elf_syminfo_data (i.e. does not use edata->next).  Is that a bug?

Thanks.

Alexander
Ian Lance Taylor May 21, 2013, 6:49 p.m. UTC | #3 
On Tue, May 21, 2013 at 9:52 AM, Alexander Monakov <amonakov@ispras.ru> wrote:
>
> 1. The documentation does not say whether reusing "state" objects is allowed.
> For instance, I'm using backtrace_simple, and then in the callback I'm
> invoking dladdr and backtrace_pcinfo to gather file-line info if available.
> Looks like at the moment it's fine, as no frame-specific information is stored
> there.

Yes, you can reuse backtrace_state objects.

> 2. The reason I'm invoking dladdr instead of backtrace_syminfo is the need to
> obtain the name of the module containing the symbol.  Is that intended?
> (IOW, would be nice if libbacktrace syminfo callback provided name and base
> address of the loaded module as well)

I'm fine with changing libbacktrace_syminfo so that it passes the
module name and the base address to the callback.

> 3. In libbacktrace/elf.c, elf_syminfo() does not seem to walk the chain of
> elf_syminfo_data (i.e. does not use edata->next).  Is that a bug?

Hmmm, yes, that does look like a bug.  Whoops.

Ian
diff mbox

Patch

diff --git a/libbacktrace/auxincl/dwarf2.h b/libbacktrace/auxincl/dwarf2.h
new file mode 100644
index 0000000..d135d8a
--- /dev/null
+++ b/libbacktrace/auxincl/dwarf2.h
@@ -0,0 +1,52 @@ 
+/* dwarf2.h -- minimal GCC dwarf2.h replacement for libbacktrace
+   Contributed by Alexander Monakov, ISP RAS
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+    (1) Redistributions of source code must retain the above copyright
+    notice, this list of conditions and the following disclaimer.
+
+    (2) Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in
+    the documentation and/or other materials provided with the
+    distribution.
+
+    (3) The name of the author may not be used to
+    endorse or promote products derived from this software without
+    specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.  */
+
+#ifndef BACKTRACE_AUX_DWARF2_H
+#define BACKTRACE_AUX_DWARF2_H
+
+/* Use the system header for the bulk of the definitions.  */
+#include <dwarf.h>
+
+/* Provide stub enum tags.  */
+enum dwarf_attribute {_dummy_dwarf_attribute};
+enum dwarf_form {_dummy_dwarf_form};
+enum dwarf_tag {_dummy_dwarf_tag};
+
+/* Define potentially missing enum values.  */
+#define DW_FORM_GNU_addr_index 0x1f01
+#define DW_FORM_GNU_str_index  0x1f02
+
+#define DW_FORM_GNU_ref_alt    0x1f20
+#define DW_FORM_GNU_strp_alt   0x1f21
+
+#define DW_LNS_extended_op 0
+
+#endif
diff --git a/libbacktrace/auxincl/filenames.h b/libbacktrace/auxincl/filenames.h
new file mode 100644
index 0000000..000dd30
--- /dev/null
+++ b/libbacktrace/auxincl/filenames.h
@@ -0,0 +1,40 @@ 
+/* filenames.h -- minimal GCC filenames.h replacement for libbacktrace
+   Contributed by Alexander Monakov, ISP RAS
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+    (1) Redistributions of source code must retain the above copyright
+    notice, this list of conditions and the following disclaimer.
+
+    (2) Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in
+    the documentation and/or other materials provided with the
+    distribution.
+
+    (3) The name of the author may not be used to
+    endorse or promote products derived from this software without
+    specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.  */
+
+#ifndef BACKTRACE_AUX_FILENAMES_H
+#define BACKTRACE_AUX_FILENAMES_H
+
+/* Assume POSIX paths.  */
+
+#define IS_DIR_SEPARATOR(c) ((c) == '/')
+#define IS_ABSOLUTE_PATH(f) ((f)[0] == '/')
+
+#endif