On Fri, 2013-01-18 at 18:48 +0100, Jan Kratochvil wrote:
On Wed, 16 Jan 2013 15:54:13 +0100, Mark Wielaard wrote:
> diff --git a/libdwfl/dwfl_module_addrsym.c b/libdwfl/dwfl_module_addrsym.c
> index fdc95fc..0e4de9f 100644
> --- a/libdwfl/dwfl_module_addrsym.c
> +++ b/libdwfl/dwfl_module_addrsym.c
> @@ -168,17 +173,19 @@ dwfl_module_addrsym (Dwfl_Module *mod, GElf_Addr addr,
> - /* First go through global symbols. mod->first_global is setup by
> - dwfl_module_getsymtab to the index of the first global symbol in
> - the module's symbol table, or -1 when unknown. All symbols with
> - local binding come first in the symbol table, then all globals. */
> - search_table (mod->first_global < 0 ? 1 : mod->first_global, syments);
> + /* First go through global symbols. mod->first_global and
> + mod->aux_first_global are setup by dwfl_module_getsymtab to the
> + index of the first global symbol in the module's symbol table, or
> + -1 when unknown. All symbols with local binding come first in
> + the symbol table, then all globals. */
> + int first_global = mod->first_global + mod->aux_first_global - 1;
aux_first_global is not initialized to -1 anywhere so in the normal case
without minisymtab it is left initialized as 0.
Yeah, good catch. And although first_global was initialized to -1 that
was really unnecessary (as you point out below load_symtab now always
sets it), because we don't use that as marker anymore. I have updated
the comment and removed that -1 initialization.
I have found for example /usr/bin/loginctl from
Symbol table '.dynsym' contains 147 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000614444 0 NOTYPE LOCAL DEFAULT ABS _edata
2: 0000000000614cd0 0 NOTYPE LOCAL DEFAULT ABS _end
3: 0000000000614444 0 NOTYPE LOCAL DEFAULT ABS __bss_start
So I agree now .dynsym may contain local symbols, but I still do not
understand how that happens (systemd does not rebuild for me locally).
Isn't it rather a bug of the build toolchain for systemd?
I thought it was a toolchain bug but understand now that if there are
relocations that depend on local symbols those symbols need to be
Otherwise it looks OK to me.
Thanks. I have merged it into master.