public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Omar Sandoval <osandov@osandov.com>, elfutils-devel@sourceware.org
Subject: Re: [PATCH 5/5] libdw: export libebl symbols
Date: Mon, 08 Jul 2019 21:14:00 -0000	[thread overview]
Message-ID: <9d92d2109319d20f1f43b031775a972532c1997a.camel@klomp.org> (raw)
In-Reply-To: <80970424804952094aaee7a0cc3279c4b8835661.1562372641.git.osandov@fb.com>

Hi,

On Fri, 2019-07-05 at 17:34 -0700, Omar Sandoval wrote:
> The main downside of the previous change to build in all libebl backend
> modules statically is that the total installed size of elfutils
> increased (from 2.1 MB to 3.5 MB in my case). This is because we have to
> statically link libebl and its backends into every binary. Instead,
> since libebl is already linked into libdw.so, we can simply export the
> libebl symbols in libdw.so for the binaries to use. This shrinks the
> total size to 1.7 MB, which is smaller than where we started.
> 
> This doesn't change the status of libebl: it is still considered
> internal and the API/ABI are still subject to change.

The status is the same, but by exporting them explicitly I am afraid
people will just start using them as if they are supported API. So if
at all possible I rather not have them exported from libdw.so.

> +ELFUITLS_0.177 {
> +  global:
> +    ebl_openbackend;
> +    ebl_openbackend_machine;
> +    ebl_openbackend_emulation;
> +    ebl_closebackend;
> +    ebl_get_elfmachine;
> +    ebl_get_elfclass;
> +    ebl_get_elfdata;
> +    ebl_backend_name;
> +    ebl_reloc_type_name;
> +    ebl_reloc_type_check;
> +    ebl_reloc_valid_use;
> +    ebl_reloc_simple_type;
> +    ebl_gotpc_reloc_check;
> +    ebl_segment_type_name;
> +    ebl_section_type_name;
> +    ebl_section_name;
> +    ebl_machine_flag_name;
> +    ebl_machine_flag_check;
> +    ebl_machine_section_flag_check;
> +    ebl_check_special_section;
> +    ebl_symbol_type_name;
> +    ebl_symbol_binding_name;
> +    ebl_dynamic_tag_name;
> +    ebl_dynamic_tag_check;
> +    ebl_check_special_symbol;
> +    ebl_data_marker_symbol;
> +    ebl_check_st_other_bits;
> +    ebl_osabi_name;
> +    ebl_core_note_type_name;
> +    ebl_object_note_type_name;
> +    ebl_object_note;
> +    ebl_check_object_attribute;
> +    ebl_check_reloc_target_type;
> +    ebl_debugscn_p;
> +    ebl_copy_reloc_p;
> +    ebl_none_reloc_p;
> +    ebl_relative_reloc_p;
> +    ebl_section_strip_p;
> +    ebl_bss_plt_p;
> +    ebl_sysvhash_entrysize;
> +    ebl_return_value_location;
> +    ebl_register_info;
> +    ebl_syscall_abi;
> +    ebl_abi_cfi;
> +    ebl_core_note;
> +    ebl_auxv_info;
> +    ebl_set_initial_registers_tid;
> +    ebl_frame_nregs;
> +    ebl_ra_offset;
> +    ebl_func_addr_mask;
> +    ebl_dwarf_to_regno;
> +    ebl_normalize_pc;
> +    ebl_unwind;
> +    ebl_resolve_sym_value;
> +} ELFUTILS_0.175;

But this is a nice starting point to see which functions could be
cleaned up and properly supported/exported.

And some can probably just be removed.
ebl_openbackend_machine is only use in a couple of tests.
ebl_openbackend_emulation doesn't seem to be used at all.

ebl_get_elfmachine can probably be replaced by simply checking
ehdr.e_machine? Likewise ebl_get_elfclass with ehdr.e_class?

The various _name functions can probably be cleaned up and exposed
(although I am not sure about the char buffer/length thing, I like them
to just return static strings).

The _check functions are only used by eu-elflint. Maybe just move them
into elflint?

ebl_syscall_abi is never used, but actually seems useful.

Not saying we should immediately do that, but the above would be some
functions that deserve some attention before we make them public.

Cheers,

Mark

  reply	other threads:[~2019-07-08 21:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06  0:35 [PATCH 0/5] elfutils: don't use dlopen() for libebl modules Omar Sandoval
2019-07-06  0:35 ` [PATCH 3/5] Add PIC and non-PIC variants of libcpu and libebl Omar Sandoval
2019-07-06  0:35 ` [PATCH 2/5] libcpu: merge libcpu_{i386,x86_64,bpf} into one library Omar Sandoval
2019-07-06  0:35 ` [PATCH 5/5] libdw: export libebl symbols Omar Sandoval
2019-07-08 21:14   ` Mark Wielaard [this message]
2019-07-06  0:35 ` [PATCH 4/5] Don't use dlopen() for libebl modules Omar Sandoval
2019-07-06  0:35 ` [PATCH 1/5] libebl: remove unnecessary variable in Makefile.am Omar Sandoval

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d92d2109319d20f1f43b031775a972532c1997a.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=osandov@osandov.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).