This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/5] libdw: export libebl symbols


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]