This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] more adjustments to elf_find_function
- From: "Jan Beulich" <JBeulich at novell dot com>
- To: <nickc at redhat dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Tue, 30 Nov 2004 17:32:49 +0100
- Subject: Re: [PATCH] more adjustments to elf_find_function
>I am not sure that this patch is quite right. There are two possible
>problems with it:
>
>1) It does not apply the same adjustment to arm_elf_find_function in
>elf32-arm.c.
That could be easily addressed; I wonder, however, why the same
(generic) code exists in two places. I didn't even know there's a second
instance of it, and for such arch-specific files I'd view this as a task
the maintainers of the arch would have to carry out (after all it must
have been them to decide the duplicate this and perhaps a lot more
functionality).
>2) I think that the transition from state==nothing_seen to
>state==symbol_seen might be in the wrong place. What happens if the
>symbols encountered are in this order:
>
> STT_LOPROC
> STT_FILENAME
> STT_FUNC
>
>The first symbol will change the state to symbol_seen, but will not
set
>'func'. The second symbol will change the state to
>file_after_symbol_seen so that when the third symbol is encountered
>'filename' will be set to NULL and no filename will be reported.
>
>I think that the change from state nothing_seen to state symbol_seen
>ought to be inside the switch() statement, at the end of STT_FUNC.
What
>do you think ?
I think it's right (at least I intended it to behave exactly as you
describe it). In that place I can't judge about the meaning of symbols
between STT_LOPROC and STT_HIPROC anyway, so considering them 'normal'
symbols seemed more obvious to me. If an arch indeed has a symbol type
that needs to be ignored here, then a new hook would be needed.
In any case the state change can't be at the end of the STT_FUNC case:
STT_OBJECT and STT_TLS (as well as any future types) ones would then be
mis-treated, and especially wrt. future extensions I used the assumption
that those (see the relatively new STT_TLS) would be 'normal' rather
than 'special' in the sense used here.
Jan