.text & text.hot section for bfd ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

.text & text.hot section for bfd ?

SandeepKsinha
If we use the callback get_section_by_name provided by bfd and try to
pass the ".text" section    as a parameter .
Will it also include the text.hot section and text.unlikely by default
into the .text . Or  will have to write three callbacks for each of
them.
If so, then how do we determine that which executables have and which dont.
I am working on dynamic optimization system, Where we start our
interpretation from the main, which is generally present in the .text
section. But, Suppose for the code of gcc, it has a text.hot and call
to main()  lies in this section,

We get an error address out of bounds ?
Any suggestions?

--
Regards,
Sandeep





A man with one watch knows what time it is; a man with two watches is
never quite sure.
Reply | Threaded
Open this post in threaded view
|

Re: .text & text.hot section for bfd ?

Nick Clifton
Hi Sandeep,

> If we use the callback get_section_by_name provided by bfd and try to
> pass the ".text" section as a parameter .
> Will it also include the text.hot section and text.unlikely by default
> into the .text.

No.

 > Or  will have to write three callbacks for each of them.

Yes.

Or in fact you will probably want to search for all sections whose name
starts with .text. and process all of those.

> If so, then how do we determine that which executables have and which dont.

Use the function bfd_map_over_sections to search through all of the
sections in a BFD.  Check the names (or attributes) of each section
against your desired search parameters.

> I am working on dynamic optimization system, Where we start our
> interpretation from the main, which is generally present in the .text
> section. But, Suppose for the code of gcc, it has a text.hot and call
> to main()  lies in this section,

Starting from main is generally a bad idea.  Almost no executable really
starts at main.  You should start from the entry point for the
executable and scan from there.

Cheers
   Nick


Reply | Threaded
Open this post in threaded view
|

Re: .text & text.hot section for bfd ?

Daniel Jacobowitz-2
On Mon, Feb 06, 2006 at 04:11:18PM +0000, Nick Clifton wrote:
> > Or  will have to write three callbacks for each of them.
>
> Yes.
>
> Or in fact you will probably want to search for all sections whose name
> starts with .text. and process all of those.

Or do it by section flags, as Nick mentioned later; SEC_CODE
(corresponding to ELF SHF_EXECINSTR).

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: .text & text.hot section for bfd ?

SandeepKsinha
In reply to this post by Nick Clifton
On 2/6/06, Nick Clifton <[hidden email]> wrote:

> Hi Sandeep,
>
> > If we use the callback get_section_by_name provided by bfd and try to
> > pass the ".text" section as a parameter .
> > Will it also include the text.hot section and text.unlikely by default
> > into the .text.
>
> No.
>
>  > Or  will have to write three callbacks for each of them.
>
> Yes.
>
> Or in fact you will probably want to search for all sections whose name
> starts with .text. and process all of those.
>
> > If so, then how do we determine that which executables have and which dont.
>
> Use the function bfd_map_over_sections to search through all of the
> sections in a BFD.  Check the names (or attributes) of each section
> against your desired search parameters.
>
> > I am working on dynamic optimization system, Where we start our
> > interpretation from the main, which is generally present in the .text
> > section. But, Suppose for the code of gcc, it has a text.hot and call
> > to main()  lies in this section,
>
> Starting from main is generally a bad idea.  Almost no executable really
> starts at main.  You should start from the entry point for the
> executable and scan from there.

For the initial cut we are working with this design, in the future
iterations we will definitely make those changes.

Thanks Nick.
--
Regards,
Sandeep



A man with one watch knows what time it is; a man with two watches is
never quite sure.