[07/14] add infcall_mmap and gcc_target_options gdbarch methods

  From: Jan Kratochvil <jan.kratochvil@redhat.com>

The compiler needed two new gdbarch methods.

The infcall_mmap method allocates memory in the inferior.
This is used when inserting the object code.

The gcc_target_options method computes some arch-specific gcc options
to pass to the compiler.  This is used to ensure that gcc generates
object code for the correct architecture.

2014-05-16  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* arch-utils.c (default_infcall_mmap)
	(default_gcc_target_options): New functions.
	* arch-utils.h (default_infcall_mmap, default_gcc_target_options):
	Declare.
	* gdbarch.h: Rebuild.
	* gdbarch.c: Rebuild.
	* gdbarch.sh (infcall_mmap, gcc_target_options): New methods.
---
 gdb/ChangeLog    | 10 ++++++++++
 gdb/arch-utils.c | 13 +++++++++++++
 gdb/arch-utils.h |  4 ++++
 gdb/gdbarch.c    | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 gdb/gdbarch.h    | 18 ++++++++++++++++++
 gdb/gdbarch.sh   | 12 ++++++++++++
 6 files changed, 103 insertions(+)
  

On 05/16/2014 11:26 PM, Tom Tromey wrote:
> The compiler needed two new gdbarch methods.
> 
> The infcall_mmap method allocates memory in the inferior.
> This is used when inserting the object code.

IMO, "infcall_mmap" is confusing....

> diff --git a/gdb/gdbarch.sh b/gdb/gdbarch.sh
> index 9f357b6..6b2bc12 100755
> --- a/gdb/gdbarch.sh
> +++ b/gdb/gdbarch.sh
> @@ -1029,6 +1029,18 @@ m:int:insn_is_jump:CORE_ADDR addr:addr::default_insn_is_jump::0
>  # Return -1 if there is insufficient buffer for a whole entry.
>  # Return 1 if an entry was read into *TYPEP and *VALP.
>  M:int:auxv_parse:gdb_byte **readptr, gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp:readptr, endptr, typep, valp
> +
> +# Allocate SIZE bytes of PROT protected page aligned memory in inferior.
> +# PROT has rwx bitmask format - bit 2 (value 4) is for readable memory, bit 1
> +# (value 2) is for writable memory and bit 0 (value 1) is for executable memory.
> +# Throw an error if it is not possible.  Returned address is always valid.
> +f:CORE_ADDR:infcall_mmap:CORE_ADDR size, unsigned prot:size, prot::default_infcall_mmap::0
> +

.... looks this hook is to allocate some target memory pages with
certain required permissions.  Probably, we can use "allocate_memory"
or "mmap".

> +# Return string (caller has to use xfree for it) with options for GCC
> +# to produce code for this target, typically "-m64", "-m32" or "-m31".
> +# These options are put before CU's DW_AT_producer compilation options so that
> +# they can override it.  Method may also return NULL.
> +m:char *:gcc_target_options:void:::default_gcc_target_options::0
>  EOF
>  }

I doubt the interface like this is sufficient for other archs, like
arm and mips, which have multiple multilibs, such as -marm/thumb,
-mfloat-abi={hard,softfp}, etc.  This hook in GDB has to take something
into account, such as gdbarch, current frame, the related bfd, etc, in
order to return a correct or compatible options for gcc to compile
source.
  

On Mon, 19 May 2014 08:10:25 +0200, Yao Qi wrote:
> > +# Allocate SIZE bytes of PROT protected page aligned memory in inferior.
> > +# PROT has rwx bitmask format - bit 2 (value 4) is for readable memory, bit 1
> > +# (value 2) is for writable memory and bit 0 (value 1) is for executable memory.
> > +# Throw an error if it is not possible.  Returned address is always valid.
> > +f:CORE_ADDR:infcall_mmap:CORE_ADDR size, unsigned prot:size, prot::default_infcall_mmap::0
> > +
> 
> .... looks this hook is to allocate some target memory pages with
> certain required permissions.  Probably, we can use "allocate_memory"
> or "mmap".

I am then for plain "mmap".  "allocate_memory" suggests me more malloc().


> > +# Return string (caller has to use xfree for it) with options for GCC
> > +# to produce code for this target, typically "-m64", "-m32" or "-m31".
> > +# These options are put before CU's DW_AT_producer compilation options so that
> > +# they can override it.  Method may also return NULL.
> > +m:char *:gcc_target_options:void:::default_gcc_target_options::0
> >  EOF
> >  }
> 
> I doubt the interface like this is sufficient for other archs, like
> arm and mips, which have multiple multilibs, such as -marm/thumb,
> -mfloat-abi={hard,softfp}, etc.  This hook in GDB has to take something
> into account, such as gdbarch, current frame, the related bfd, etc, in
> order to return a correct or compatible options for gcc to compile
> source.

It already already takes 'gdbarch' as its parameter.  If it is not enough some
more parameters can be added.  But IMO those should be added only when this
method gets implemented for arch which needs such parameter.


Thanks,
Jan
  

On Mon, 19 May 2014 08:40:19 +0200, Jan Kratochvil wrote:
> On Mon, 19 May 2014 08:10:25 +0200, Yao Qi wrote:
> > > +# Return string (caller has to use xfree for it) with options for GCC
> > > +# to produce code for this target, typically "-m64", "-m32" or "-m31".
> > > +# These options are put before CU's DW_AT_producer compilation options so that
> > > +# they can override it.  Method may also return NULL.
> > > +m:char *:gcc_target_options:void:::default_gcc_target_options::0
> > >  EOF
> > >  }
> > 
> > I doubt the interface like this is sufficient for other archs, like
> > arm and mips, which have multiple multilibs, such as -marm/thumb,
> > -mfloat-abi={hard,softfp}, etc.  This hook in GDB has to take something
> > into account, such as gdbarch, current frame, the related bfd, etc, in
> > order to return a correct or compatible options for gcc to compile
> > source.
> 
> It already already takes 'gdbarch' as its parameter.  If it is not enough some
> more parameters can be added.  But IMO those should be added only when this
> method gets implemented for arch which needs such parameter.

Oh, you maybe mean that default_gcc_target_options should just error() out as
the default implementation does not work for many existing archs.  And only
tested archs should get implemented their gcc_target_options (even if they
look as the current default_gcc_target_options).

I was considering it but I was expecting 99% of arch will look the same but if
it is not the case the default really can be error().


Jan
  

On 05/19/2014 02:40 PM, Jan Kratochvil wrote:
>> I doubt the interface like this is sufficient for other archs, like
>> > arm and mips, which have multiple multilibs, such as -marm/thumb,
>> > -mfloat-abi={hard,softfp}, etc.  This hook in GDB has to take something
>> > into account, such as gdbarch, current frame, the related bfd, etc, in
>> > order to return a correct or compatible options for gcc to compile
>> > source.
> It already already takes 'gdbarch' as its parameter.  If it is not enough some
> more parameters can be added.  But IMO those should be added only when this
> method gets implemented for arch which needs such parameter.

We can add these parameters when we really need them.  That is fine.
However, I still doubt whether GDB is able to return the correct gcc
options by means of analysing executable only.  Supposing the executable
is compiled with "-march=armv7-a -mthumb -mfloat-abi=hard -mfpu=neon",
GDB should know the code is thumb and float-abi is hard.  How can GDB
tell "-march=armv7-a -mfpu=neon" is used too?  If GDB doesn't know,
what options this hook should return? and is the object code
compiled "on the fly" still compatible to the inferior code and target
runtime?
  

> On 05/19/2014 02:40 PM, Jan Kratochvil wrote:

> >> I doubt the interface like this is sufficient for other archs, like

> >> > arm and mips, which have multiple multilibs, such as -marm/thumb,

> >> > -mfloat-abi={hard,softfp}, etc.  This hook in GDB has to take something

> >> > into account, such as gdbarch, current frame, the related bfd, etc, in

> >> > order to return a correct or compatible options for gcc to compile

> >> > source.

> > It already already takes 'gdbarch' as its parameter.  If it is not enough some

> > more parameters can be added.  But IMO those should be added only when this

> > method gets implemented for arch which needs such parameter.

> 

> We can add these parameters when we really need them.  That is fine.

> However, I still doubt whether GDB is able to return the correct gcc

> options by means of analysing executable only.  Supposing the executable

> is compiled with "-march=armv7-a -mthumb -mfloat-abi=hard -mfpu=neon",

> GDB should know the code is thumb and float-abi is hard.  How can GDB

> tell "-march=armv7-a -mfpu=neon" is used too?  If GDB doesn't know,

> what options this hook should return? and is the object code

> compiled "on the fly" still compatible to the inferior code and target

> runtime?

> 

This will probably only work for host == target with the default compiler
options. Any other cases are doomed to fail. So your example is one out 
of many.

We may consider picking the cu die for the current $pc and extract the compiler
options from DW_AT_producer[1]. But this requires parsing the necessary bits out
of a string. Adding something like DW_AT_producer_options to dwarf would make
things more straight forward.

[1] DW_AT_producer    : [...] -mtune=generic -march=x86-64 -g

-Sanimir

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
  

On Mon, 19 May 2014 10:26:43 +0200, Agovic, Sanimir wrote:
> We may consider picking the cu die for the current $pc and extract the compiler
> options from DW_AT_producer[1]. But this requires parsing the necessary bits out
> of a string. Adding something like DW_AT_producer_options to dwarf would make
> things more straight forward.
> 
> [1] DW_AT_producer    : [...] -mtune=generic -march=x86-64 -g

This is already done in this patchset.  I expect if one uses the compiled
expressions one is probably using -g non-stripped inferior.

This gdbarch gcc_target_options method is there only as some fallback for
stripped / non-g / old gcc / -gno-record-gcc-switches inferiors.


Jan