path to find libcc1.so?

path to find libcc1.so?

[Doug Evans]

Hi.

I was reading the new "compile" code and a question occurred to me.
Do we want to give the user a parameter to specify the path of libcc1.so?
(say if it's in a non-standard location)
Or is the plan to tell users to use existing mechanisms
(LD_LIBRARY_PATH, et.al.)?

[If we provide a parameter, presumably we'll then need to do safe-path-checking,
but we already have code for that for libthread_db.]

Re: path to find libcc1.so?

[Eli Zaretskii]

> Date: Fri, 12 Dec 2014 16:22:38 -0800
> From: Doug Evans <dje@google.com>
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> I was reading the new "compile" code and a question occurred to me.
> Do we want to give the user a parameter to specify the path of libcc1.so?

Shouldn't "gcc -print-file-name" know how to find it?

> (say if it's in a non-standard location)
> Or is the plan to tell users to use existing mechanisms
> (LD_LIBRARY_PATH, et.al.)?

LD_LIBRARY_PATH doesn't exist on Windows, for one.

Re: path to find libcc1.so?

[Jan Kratochvil]

On Sat, 13 Dec 2014 01:22:38 +0100, Doug Evans wrote:
> I was reading the new "compile" code and a question occurred to me.
> Do we want to give the user a parameter to specify the path of libcc1.so?
> (say if it's in a non-standard location)
> Or is the plan to tell users to use existing mechanisms
> (LD_LIBRARY_PATH, et.al.)?

It is assumed + I use $LD_LIBRARY_PATH.

I find the GDB compile project is at much too early stage than to care about
this.  It needs some additional features (such as to use it by default for the
"print" command etc. etc.) to make it really practically useful, additionally
it will be useful IMO only since the C++ support which is a new project ahead.

But if we should care about it: I think libcc1.so can be arbitrary one, it
only provides RPC interface to the target compiler which it
fork()s+exec()utes.  Target compiler is already being search to match the
inferior arch (see GDB gdbarch's gnu_triplet_regexp).  There is gdb<->libcc1
version check (GCC_FE_VERSION_0) and libcc1<->gcc version check
(GCC_C_FE_VERSION_0) but so far there exists only one protocol version so
I also find a bit premature to deal with searching for matching libcc1 when
currently any one has to match.

I wanted to try to check how does it search+work with s390x cross target but
I failed to build gcc-5.0 for s390x, filed:
	s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300


On Sat, 13 Dec 2014 08:53:02 +0100, Eli Zaretskii wrote:
> > Date: Fri, 12 Dec 2014 16:22:38 -0800
> > From: Doug Evans <dje@google.com>
> > Cc: gdb-patches <gdb-patches@sourceware.org>
> > 
> > I was reading the new "compile" code and a question occurred to me.
> > Do we want to give the user a parameter to specify the path of libcc1.so?
> 
> Shouldn't "gcc -print-file-name" know how to find it?

While 'gcc -print-file-name=libcc1.so' really works for me it brings
a chicken-and-egg problem.

Currently the search for a matching compiler (like x86_64-redhat-linux-gcc
vs. s390x-linux-gnu-gcc) is being done by libcc1.so which ... is backwards.


Jan

Re: path to find libcc1.so?

[Doug Evans]

On Sat, Dec 13, 2014 at 10:56 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 13 Dec 2014 01:22:38 +0100, Doug Evans wrote:
>> I was reading the new "compile" code and a question occurred to me.
>> Do we want to give the user a parameter to specify the path of libcc1.so?
>> (say if it's in a non-standard location)
>> Or is the plan to tell users to use existing mechanisms
>> (LD_LIBRARY_PATH, et.al.)?
>
> It is assumed + I use $LD_LIBRARY_PATH.
>
> I find the GDB compile project is at much too early stage than to care about
> this.

Early adopters and those who want to contribute may find it preferable
to use, e.g., ~/.gdbinit.

If this is something we eventually want to do, doing it now will help
people we want/need.

Plus it's, what, 10 lines of (real) code?

Re: path to find libcc1.so?

[Jan Kratochvil]

On Sat, 13 Dec 2014 20:57:35 +0100, Doug Evans wrote:
> Early adopters and those who want to contribute may find it preferable
> to use, e.g., ~/.gdbinit.
> 
> If this is something we eventually want to do, doing it now will help
> people we want/need.
> 
> Plus it's, what, 10 lines of (real) code?

It is then questionable whether there should also be a GDB option where to
find the GCC driver.  Currently gcc/libcc1/findcomp.cc searches it in $PATH.


Jan

Re: path to find libcc1.so?

[Doug Evans]

On Sat, Dec 13, 2014 at 12:16 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 13 Dec 2014 20:57:35 +0100, Doug Evans wrote:
>> Early adopters and those who want to contribute may find it preferable
>> to use, e.g., ~/.gdbinit.
>>
>> If this is something we eventually want to do, doing it now will help
>> people we want/need.
>>
>> Plus it's, what, 10 lines of (real) code?
>
> It is then questionable whether there should also be a GDB option where to
> find the GCC driver.  Currently gcc/libcc1/findcomp.cc searches it in $PATH.

That is a good question.

If I configure gcc with a certain --prefix,
and link libcc1.so, with, say, --rpath,
do/should I need to do anything more?

[for a normal installation (libcc1.so has not been copied out of $prefix and
into some random directory) should libcc1.so be able to find its gcc
on its own?]

Re: path to find libcc1.so?

[Doug Evans]

On Sat, Dec 13, 2014 at 1:49 PM, Doug Evans <dje@google.com> wrote:
> If I configure gcc with a certain --prefix,
> and link libcc1.so, with, say, --rpath,
> do/should I need to do anything more?

Sorry, poor choice of words.

By "link" I meant just the addition of --rpath.
I realize libcc1.so is dlopen'd.

Re: path to find libcc1.so?

[Jan Kratochvil]

On Sat, 13 Dec 2014 22:49:50 +0100, Doug Evans wrote:
> On Sat, Dec 13, 2014 at 12:16 PM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
> > On Sat, 13 Dec 2014 20:57:35 +0100, Doug Evans wrote:
> >> Early adopters and those who want to contribute may find it preferable
> >> to use, e.g., ~/.gdbinit.
> >>
> >> If this is something we eventually want to do, doing it now will help
> >> people we want/need.
> >>
> >> Plus it's, what, 10 lines of (real) code?
> >
> > It is then questionable whether there should also be a GDB option where to
> > find the GCC driver.  Currently gcc/libcc1/findcomp.cc searches it in $PATH.
> 
> That is a good question.
> 
> If I configure gcc with a certain --prefix,
> and link libcc1.so, with, say, --rpath,
> do/should I need to do anything more?
> 
> [for a normal installation (libcc1.so has not been copied out of $prefix and
> into some random directory) should libcc1.so be able to find its gcc
> on its own?]

Currently that libcc1.so will just look at $PATH and find (probably - unless
you modify your $PATH) rather your /usr/bin/x86_64-redhat-linux-gcc instead.

In some way it is correct.  libcc1.so is independent from the GCC driver.
libcc1.so just translates API into RPC calls and those RPC calls are
received/processed by libcc1plugin.so (loaded due to -fplugin=libcc1plugin
passed by libcc1.so to its found gcc driver):
	/home/jkratoch/redhat/gcchead-root/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/libcc1plugin.so

libcc1.so (the RPC calls interface) could be even implemented by GDB itself
but for some reason Tom put it at the same source location as the other half
(RPC receiver/peer libcc1plugin.so).

This is why I proposed think if there should be a GDB option where to locate
libcc1.so there could be also a GDB option where to locate the GCC driver,
those are technically two mostly independent binaries.

One could also have a single GDB option to specify where to locate the GCC
driver only.  And 'thatpath/gcc -print-file-name=libcc1.so' would really
provide the libcc1.so location.


Jan