This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH 07/14] add infcall_mmap and gcc_target_options gdbarch methods
- From: "Agovic, Sanimir" <sanimir dot agovic at intel dot com>
- To: 'Yao Qi' <yao at codesourcery dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 19 May 2014 08:26:43 +0000
- Subject: RE: [PATCH 07/14] add infcall_mmap and gcc_target_options gdbarch methods
- Authentication-results: sourceware.org; auth=none
- References: <1400253995-12333-1-git-send-email-tromey at redhat dot com> <1400253995-12333-8-git-send-email-tromey at redhat dot com> <5379A051 dot 9040209 at codesourcery dot com> <20140519064019 dot GA19564 at host2 dot jankratochvil dot net> <5379B528 dot 5040607 at codesourcery dot com>
> 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