* Why does solib_open do what it does? @ 2003-06-17 19:01 Kris Warkentin 2003-06-17 19:13 ` Daniel Jacobowitz 0 siblings, 1 reply; 31+ messages in thread From: Kris Warkentin @ 2003-06-17 19:01 UTC (permalink / raw) To: Gdb@Sources.Redhat.Com I'm looking at solib.c:solib_open() and as I go down the list: Search order: 1 * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX. 2 * If path is absolute or relative, look for it literally (unmodified). 3 * Look in SOLIB_SEARCH_PATH. 4 * If available, use target defined search function. 5 * Look in inferior's $PATH. 6 * Look in inferior's $LD_LIBRARY_PATH. I'm puzzled. Why are we testing for the existence of solib_search_path before checking 5 and 6? cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 19:01 Why does solib_open do what it does? Kris Warkentin @ 2003-06-17 19:13 ` Daniel Jacobowitz 2003-06-17 19:14 ` Kris Warkentin 0 siblings, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2003-06-17 19:13 UTC (permalink / raw) To: Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote: > I'm looking at solib.c:solib_open() and as I go down the list: > > Search order: > 1 * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX. > 2 * If path is absolute or relative, look for it literally (unmodified). > 3 * Look in SOLIB_SEARCH_PATH. > 4 * If available, use target defined search function. > 5 * Look in inferior's $PATH. > 6 * Look in inferior's $LD_LIBRARY_PATH. > > I'm puzzled. Why are we testing for the existence of solib_search_path > before checking 5 and 6? You'll have to get Kevin's opinion, but it looks like a paste-o to me. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 19:13 ` Daniel Jacobowitz @ 2003-06-17 19:14 ` Kris Warkentin 2003-06-17 19:37 ` Elena Zannoni 2003-06-17 20:01 ` Kevin Buettner 0 siblings, 2 replies; 31+ messages in thread From: Kris Warkentin @ 2003-06-17 19:14 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Gdb@Sources.Redhat.Com > On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote: > > I'm looking at solib.c:solib_open() and as I go down the list: > > > > Search order: > > 1 * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX. > > 2 * If path is absolute or relative, look for it literally (unmodified). > > 3 * Look in SOLIB_SEARCH_PATH. > > 4 * If available, use target defined search function. > > 5 * Look in inferior's $PATH. > > 6 * Look in inferior's $LD_LIBRARY_PATH. > > > > I'm puzzled. Why are we testing for the existence of solib_search_path > > before checking 5 and 6? > > You'll have to get Kevin's opinion, but it looks like a paste-o to me. That's what I was thinking too. A customer reported that when they don't set solib-search-path, all of a sudden gdb isn't finding solibs that used to be found in LD_LIBRARY_PATH. You think it's okay for me to fix it? cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 19:14 ` Kris Warkentin @ 2003-06-17 19:37 ` Elena Zannoni 2003-06-17 19:47 ` Kris Warkentin 2003-06-17 20:01 ` Kevin Buettner 1 sibling, 1 reply; 31+ messages in thread From: Elena Zannoni @ 2003-06-17 19:37 UTC (permalink / raw) To: Kris Warkentin; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com Kris Warkentin writes: > > On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote: > > > I'm looking at solib.c:solib_open() and as I go down the list: > > > > > > Search order: > > > 1 * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX. > > > 2 * If path is absolute or relative, look for it literally > (unmodified). > > > 3 * Look in SOLIB_SEARCH_PATH. > > > 4 * If available, use target defined search function. > > > 5 * Look in inferior's $PATH. > > > 6 * Look in inferior's $LD_LIBRARY_PATH. > > > > > > I'm puzzled. Why are we testing for the existence of solib_search_path > > > before checking 5 and 6? > > > > You'll have to get Kevin's opinion, but it looks like a paste-o to me. > > That's what I was thinking too. A customer reported that when they don't > set solib-search-path, all of a sudden gdb isn't finding solibs that used to > be found in LD_LIBRARY_PATH. > > You think it's okay for me to fix it? > > cheers, > > Kris > can you do some cvs annotate/diffs ? maybe you'll see when that was introduced, and find a changelog that explains things. elena ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 19:37 ` Elena Zannoni @ 2003-06-17 19:47 ` Kris Warkentin 0 siblings, 0 replies; 31+ messages in thread From: Kris Warkentin @ 2003-06-17 19:47 UTC (permalink / raw) To: Elena Zannoni; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com > can you do some cvs annotate/diffs ? maybe you'll see when that was > introduced, and find a changelog that explains things. It's from the first revision of solib_open from msnyder back in November of 2000. No explanation in the logs. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 19:14 ` Kris Warkentin 2003-06-17 19:37 ` Elena Zannoni @ 2003-06-17 20:01 ` Kevin Buettner 2003-06-17 20:15 ` Kris Warkentin 1 sibling, 1 reply; 31+ messages in thread From: Kevin Buettner @ 2003-06-17 20:01 UTC (permalink / raw) To: Kris Warkentin, Daniel Jacobowitz; +Cc: Gdb@Sources.Redhat.Com On Jun 17, 3:14pm, Kris Warkentin wrote: > Subject: Re: Why does solib_open do what it does? > > On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote: > > > I'm looking at solib.c:solib_open() and as I go down the list: > > > > > > Search order: > > > 1 * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX. > > > 2 * If path is absolute or relative, look for it literally > (unmodified). > > > 3 * Look in SOLIB_SEARCH_PATH. > > > 4 * If available, use target defined search function. > > > 5 * Look in inferior's $PATH. > > > 6 * Look in inferior's $LD_LIBRARY_PATH. > > > > > > I'm puzzled. Why are we testing for the existence of solib_search_path > > > before checking 5 and 6? > > > > You'll have to get Kevin's opinion, but it looks like a paste-o to me. > > That's what I was thinking too. A customer reported that when they don't > set solib-search-path, all of a sudden gdb isn't finding solibs that used to > be found in LD_LIBRARY_PATH. It sounds to me like the solibs in question were actually being found via solib-search-path, not LD_LIBRARY_PATH. I think the problem with using LD_LIBRARY_PATH is that the paths won't be correct without some sort of adjustment. I.e, the paths provided by LD_LIBRARY_PATH are target filesystem paths, not host paths. > You think it's okay for me to fix it? Not yet. I want to study the code some more first. ... Actually, the one that bothers me is (2). I think we ought to be doing (2) after (3). Kevin ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 20:01 ` Kevin Buettner @ 2003-06-17 20:15 ` Kris Warkentin 2003-06-17 20:24 ` Kevin Buettner 0 siblings, 1 reply; 31+ messages in thread From: Kris Warkentin @ 2003-06-17 20:15 UTC (permalink / raw) To: Kevin Buettner, Daniel Jacobowitz; +Cc: Gdb@Sources.Redhat.Com > > That's what I was thinking too. A customer reported that when they don't > > set solib-search-path, all of a sudden gdb isn't finding solibs that used to > > be found in LD_LIBRARY_PATH. > > It sounds to me like the solibs in question were actually being found via > solib-search-path, not LD_LIBRARY_PATH. > > I think the problem with using LD_LIBRARY_PATH is that the paths > won't be correct without some sort of adjustment. I.e, the paths > provided by LD_LIBRARY_PATH are target filesystem paths, not host > paths. Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong since the only util that should be concerned with that is the runtime loader. Ideally, ld should be filling in the path where it found the lib which can then be used with solib-absolute-prefix or some such. > > You think it's okay for me to fix it? > > Not yet. I want to study the code some more first. > > Actually, the one that bothers me is (2). I think we ought to be doing > (2) after (3). You may be right there. I suppose we want to give the user every opportunity to override things. I specifically put the target-defined search function AFTER the solib-search-path lookup for just that reason. If you're going to move 2, I would say it should be after the target defined one so that both users and targets get a say before gdb starts looking in places that could potentially have conflicting solibs. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 20:15 ` Kris Warkentin @ 2003-06-17 20:24 ` Kevin Buettner 2003-06-18 0:14 ` Michael Snyder 0 siblings, 1 reply; 31+ messages in thread From: Kevin Buettner @ 2003-06-17 20:24 UTC (permalink / raw) To: Daniel Jacobowitz, Kevin Buettner, Kris Warkentin Cc: msnyder, Gdb@Sources.Redhat.Com On Jun 17, 4:15pm, Kris Warkentin wrote: > > > That's what I was thinking too. A customer reported that when they > don't > > > set solib-search-path, all of a sudden gdb isn't finding solibs that > used to > > > be found in LD_LIBRARY_PATH. > > > > It sounds to me like the solibs in question were actually being found via > > solib-search-path, not LD_LIBRARY_PATH. > > > > I think the problem with using LD_LIBRARY_PATH is that the paths > > won't be correct without some sort of adjustment. I.e, the paths > > provided by LD_LIBRARY_PATH are target filesystem paths, not host > > paths. > > Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong > since the only util that should be concerned with that is the runtime > loader. Ideally, ld should be filling in the path where it found the lib > which can then be used with solib-absolute-prefix or some such. Right. I think Michael added the searches on $PATH and $LD_LIBRARY_PATH for native ports, but it's not clear to me that these searches are actually needed. Michael, any comments? > > > You think it's okay for me to fix it? > > > > Not yet. I want to study the code some more first. > > > > Actually, the one that bothers me is (2). I think we ought to be doing > > (2) after (3). > > You may be right there. I suppose we want to give the user every > opportunity to override things. I specifically put the target-defined > search function AFTER the solib-search-path lookup for just that reason. If > you're going to move 2, I would say it should be after the target defined > one so that both users and targets get a say before gdb starts looking in > places that could potentially have conflicting solibs. Sure. That sounds right to me. If you want to submit a patch for doing this, that'd be very much appreciated. Thanks, Kevin ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-17 20:24 ` Kevin Buettner @ 2003-06-18 0:14 ` Michael Snyder 2003-06-18 1:43 ` Kris Warkentin 0 siblings, 1 reply; 31+ messages in thread From: Michael Snyder @ 2003-06-18 0:14 UTC (permalink / raw) To: Kevin Buettner; +Cc: Daniel Jacobowitz, Kris Warkentin, Gdb@Sources.Redhat.Com Kevin Buettner wrote: > On Jun 17, 4:15pm, Kris Warkentin wrote: > > >>>>That's what I was thinking too. A customer reported that when they >>> >>don't >> >>>>set solib-search-path, all of a sudden gdb isn't finding solibs that >>> >>used to >> >>>>be found in LD_LIBRARY_PATH. >>> >>>It sounds to me like the solibs in question were actually being found via >>>solib-search-path, not LD_LIBRARY_PATH. >>> >>>I think the problem with using LD_LIBRARY_PATH is that the paths >>>won't be correct without some sort of adjustment. I.e, the paths >>>provided by LD_LIBRARY_PATH are target filesystem paths, not host >>>paths. >> >>Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong >>since the only util that should be concerned with that is the runtime >>loader. Ideally, ld should be filling in the path where it found the lib >>which can then be used with solib-absolute-prefix or some such. > > > Right. > > I think Michael added the searches on $PATH and $LD_LIBRARY_PATH for > native ports, but it's not clear to me that these searches are actually > needed. > > Michael, any comments? I don't remember. ;-( I'll just remark that ld puts full paths in for some libs, and not for others. That's why there are two variables, SOLIB-SEARCH-PATH and SOLIB-ABSOLUTE-PREFIX. One is the prefix that goes before everything (even rooted filespecs), and the other is the additional prefix that goes before an un-rooted filespec. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 0:14 ` Michael Snyder @ 2003-06-18 1:43 ` Kris Warkentin 2003-06-18 5:33 ` Kevin Buettner 0 siblings, 1 reply; 31+ messages in thread From: Kris Warkentin @ 2003-06-18 1:43 UTC (permalink / raw) To: Michael Snyder, Kevin Buettner; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com > > Michael, any comments? > > I don't remember. ;-( > I'll just remark that ld puts full paths in for some libs, and not for others. > That's why there are two variables, SOLIB-SEARCH-PATH and > SOLIB-ABSOLUTE-PREFIX. One is the prefix that goes before everything > (even rooted filespecs), and the other is the additional prefix that > goes before an un-rooted filespec. Okay then, here's what I propose. 1) Change the order as Kevin suggested earlier. This give the user plenty of opportunity to tell gdb how to find the solibs before we thrash about desperately in LD_LIBRARY_PATH, etc. 2) Take out the solib_search_path check in the if(found_file <0 && solib_search_path != NULL) parts of the last two desperation plays. I don't think there's any reason for them. I have a feeling that we want to leave the last two searches in place simply because native debugging is the most common and they probably catch a lot of action. Most people doing remote debugging are setting up their solib-absolute-prefix and such properly anyway. Sound reasonable? cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 1:43 ` Kris Warkentin @ 2003-06-18 5:33 ` Kevin Buettner 2003-06-18 12:11 ` Kris Warkentin 2003-06-18 18:41 ` Michael Snyder 0 siblings, 2 replies; 31+ messages in thread From: Kevin Buettner @ 2003-06-18 5:33 UTC (permalink / raw) To: Kris Warkentin, Michael Snyder, Kevin Buettner Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com On Jun 17, 9:54pm, Kris Warkentin wrote: > > > Michael, any comments? > > > > I don't remember. ;-( > > I'll just remark that ld puts full paths in for some libs, and not for > others. > > That's why there are two variables, SOLIB-SEARCH-PATH and > > SOLIB-ABSOLUTE-PREFIX. One is the prefix that goes before everything > > (even rooted filespecs), and the other is the additional prefix that > > goes before an un-rooted filespec. > > Okay then, here's what I propose. > > 1) Change the order as Kevin suggested earlier. This give the user plenty > of opportunity to tell gdb how to find the solibs before we thrash about > desperately in LD_LIBRARY_PATH, etc. Definitely okay. > 2) Take out the solib_search_path check in the if(found_file <0 && > solib_search_path != NULL) parts of the last two desperation plays. I don't > think there's any reason for them. Wow. Good catch. I don't understand them either. But... > I have a feeling that we want to leave the last two searches in place simply > because native debugging is the most common and they probably catch a lot of > action. Most people doing remote debugging are setting up their > solib-absolute-prefix and such properly anyway. Given the fact that these tests are here, I don't think that the $PATH and $LD_LIBRARY_PATH checks are ever actually used for native debugging. After all, who bothers to set solib_search_path when doing native debugging? And if you do set solib_search_path, doesn't it seem strange that these additional checks suddenly become enabled? So, at this point we have two choices: a) Do away with the $PATH and $LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove the ``solib_search_path != NULL'' check. If we can actually convince ourselves that leaving in the $PATH and $LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to go. At the moment, however, I'm strongly leaning towards option a. In fact, for remote debugging, leaving these checks in is rather dangerous. If, for some reason, the shared lib is not found via either solib-absolute-prefix or solib-search-path, we don't want to search paths on the host file system which refer to the hosts libraries. If the file is found via one of these paths, it is almost certainly wrong, and I've seen cases where this can cause wildly unpredictable behavior. (E.g, segfaults on the target, or breakpoints being hit at strange places.) I think I could be convinced to leave these checks in if we were to replace that ``solib_search_path != NULL'' conjunct with ``solib_absolute_prefix == NULL'' instead. That is, if you set solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never be considered. (I guess there were actually three choices. We'll call this one option c.) Opinions? Kevin ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 5:33 ` Kevin Buettner @ 2003-06-18 12:11 ` Kris Warkentin 2003-06-18 15:07 ` Kris Warkentin 2003-06-18 18:45 ` Michael Snyder 2003-06-18 18:41 ` Michael Snyder 1 sibling, 2 replies; 31+ messages in thread From: Kris Warkentin @ 2003-06-18 12:11 UTC (permalink / raw) To: Kevin Buettner, Michael Snyder; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com > Given the fact that these tests are here, I don't think that the $PATH > and $LD_LIBRARY_PATH checks are ever actually used for native > debugging. > > After all, who bothers to set solib_search_path when doing native > debugging? And if you do set solib_search_path, doesn't it seem > strange that these additional checks suddenly become enabled? Hmm...good point. It's probably completely unexercised code. > So, at this point we have two choices: a) Do away with the $PATH and > $LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove > the ``solib_search_path != NULL'' check. > > If we can actually convince ourselves that leaving in the $PATH and > $LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to > go. At the moment, however, I'm strongly leaning towards option a. Well, we had some customers complain that LD_LIBRARY_PATH stopped working for them when they stopped setting solib-search-path. They were using it for remote debugging (somewhat questionable I know) because they have a central build server that stores most of their libs and then developers systems have a mount. The administrators set LD_LIBRARY_PATH specifically for gdb to find these libs when debugging remote targets. They'll probably whine if I take it out. Really though, the only places I can see this being useful is cases like this and when you've got a misbehaving linker which doesn't fill in the full path. > In fact, for remote debugging, leaving these checks in is rather > dangerous. If, for some reason, the shared lib is not found via > either solib-absolute-prefix or solib-search-path, we don't want > to search paths on the host file system which refer to the hosts > libraries. If the file is found via one of these paths, it is > almost certainly wrong, and I've seen cases where this can cause > wildly unpredictable behavior. (E.g, segfaults on the target, or > breakpoints being hit at strange places.) This was my major problem with checking LD_LIBRARY_PATH. > I think I could be convinced to leave these checks in if we > were to replace that ``solib_search_path != NULL'' conjunct with > ``solib_absolute_prefix == NULL'' instead. That is, if you set > solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never > be considered. (I guess there were actually three choices. We'll > call this one option c.) Well, that wouldn't help my customers since we do set solib-absolute-prefix. On the other hand, there IS solib-search-path and .gdbinit files so I don't really have a problem with telling them that the LD_L... checking has gone away. I'll leave the decision to you. I'm just going to remove the solib_search_path != NULL checks from our shipping version and mark the behaviour as deprecated if necessary. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 12:11 ` Kris Warkentin @ 2003-06-18 15:07 ` Kris Warkentin 2003-06-18 18:52 ` Michael Snyder 2003-06-18 18:45 ` Michael Snyder 1 sibling, 1 reply; 31+ messages in thread From: Kris Warkentin @ 2003-06-18 15:07 UTC (permalink / raw) To: Kris Warkentin, Kevin Buettner, Michael Snyder Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com I believe the comment does not accurately reflect the code. Here is my proposal for the new comment using the search algorithm rather than search order: Search algorithm: * If there is a solib_absolute_prefix and path is absolute: * Search for solib_absolute_prefix/path. * else * Look for it literally (unmodified). * Look in SOLIB_SEARCH_PATH. * If available, use target defined search function. * Look in inferior's $PATH. * Look in inferior's $LD_LIBRARY_PATH. The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat more literal. It's only used if the path is absolute. Then the question is, do we think this is correct? Should we be searching literally at this point or defer that until later? cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 15:07 ` Kris Warkentin @ 2003-06-18 18:52 ` Michael Snyder 2003-06-18 19:09 ` Kris Warkentin 2003-06-18 19:14 ` Daniel Jacobowitz 0 siblings, 2 replies; 31+ messages in thread From: Michael Snyder @ 2003-06-18 18:52 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Daniel Jacobowitz, Gdb@Sources.Redhat.Com Kris Warkentin wrote: > I believe the comment does not accurately reflect the code. Here is my > proposal for the new comment using the search algorithm rather than search > order: > > Search algorithm: > * If there is a solib_absolute_prefix and path is absolute: > * Search for solib_absolute_prefix/path. > * else > * Look for it literally (unmodified). > * Look in SOLIB_SEARCH_PATH. I'm not sure -- but do you think it should be /SOLIB_ABSOLUTE_PREFIX/SOLIB_SEARCH_PATH? Or maybe both? > * If available, use target defined search function. > * Look in inferior's $PATH. > * Look in inferior's $LD_LIBRARY_PATH. I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. But come to think of it, do remote targets even have environment variables? And if so -- do they inherit them from gdb / the host? If there's a gdbserver-type situation, and if the server is able to provide the true environment variables from the target, then yes, we should use these. But I don't recall any gdbserver ever offering that functionality. > The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat more > literal. I think it's supposed to be literal. > It's only used if the path is absolute. Then the question is, do > we think this is correct? Should we be searching literally at this point or > defer that until later? > > cheers, > > Kris > > > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 18:52 ` Michael Snyder @ 2003-06-18 19:09 ` Kris Warkentin 2003-06-18 19:20 ` Andrew Cagney 2003-06-18 20:10 ` Michael Snyder 2003-06-18 19:14 ` Daniel Jacobowitz 1 sibling, 2 replies; 31+ messages in thread From: Kris Warkentin @ 2003-06-18 19:09 UTC (permalink / raw) To: Michael Snyder; +Cc: Kevin Buettner, Daniel Jacobowitz, Gdb@Sources.Redhat.Com > Kris Warkentin wrote: > > I believe the comment does not accurately reflect the code. Here is my > > proposal for the new comment using the search algorithm rather than search > > order: > > > > Search algorithm: > > * If there is a solib_absolute_prefix and path is absolute: > > * Search for solib_absolute_prefix/path. > > * else > > * Look for it literally (unmodified). > > * Look in SOLIB_SEARCH_PATH. > > I'm not sure -- but do you think it should be > /SOLIB_ABSOLUTE_PREFIX/SOLIB_SEARCH_PATH? > Or maybe both? The problem is that you don't have the freedom to define an arbitrary path if you always prepend solib-abs-pref to it. You can always put the full path in your solib-search-path if you need to. > > * If available, use target defined search function. > > * Look in inferior's $PATH. > > * Look in inferior's $LD_LIBRARY_PATH. > > I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. > But come to think of it, do remote targets even have environment variables? > And if so -- do they inherit them from gdb / the host? If there's a > gdbserver-type situation, and if the server is able to provide the true > environment variables from the target, then yes, we should use these. > But I don't recall any gdbserver ever offering that functionality. Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'. This determines whether gdb will send it's environment to the target or whether the target will inherit from the pdebug server. > > The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat more > > literal. > > I think it's supposed to be literal. True. Just never thought of it that way. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 19:09 ` Kris Warkentin @ 2003-06-18 19:20 ` Andrew Cagney 2003-06-18 20:10 ` Michael Snyder 1 sibling, 0 replies; 31+ messages in thread From: Andrew Cagney @ 2003-06-18 19:20 UTC (permalink / raw) To: Kris Warkentin, Michael Snyder Cc: Kevin Buettner, Daniel Jacobowitz, Gdb@Sources.Redhat.Com > * If available, use target defined search function. >> > * Look in inferior's $PATH. >> > * Look in inferior's $LD_LIBRARY_PATH. > >> >> I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. >> But come to think of it, do remote targets even have environment > > variables? > >> And if so -- do they inherit them from gdb / the host? If there's a >> gdbserver-type situation, and if the server is able to provide the true >> environment variables from the target, then yes, we should use these. >> But I don't recall any gdbserver ever offering that functionality. > > > Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'. > This determines whether gdb will send it's environment to the target or > whether the target will inherit from the pdebug server. This is a long standing design bug. When it comes to the environment, GDB should be strictly using target vector methods. The native target could then look in the hosts environment, the remote target query the remote end. Andrew ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 19:09 ` Kris Warkentin 2003-06-18 19:20 ` Andrew Cagney @ 2003-06-18 20:10 ` Michael Snyder 2003-06-18 20:17 ` Kris Warkentin 1 sibling, 1 reply; 31+ messages in thread From: Michael Snyder @ 2003-06-18 20:10 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Daniel Jacobowitz, Gdb@Sources.Redhat.Com Kris Warkentin wrote: >msnyder: >>Kris Warkentin wrote: >>I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. >>But come to think of it, do remote targets even have environment >>variables? > >>And if so -- do they inherit them from gdb / the host? If there's a >>gdbserver-type situation, and if the server is able to provide the true >>environment variables from the target, then yes, we should use these. >>But I don't recall any gdbserver ever offering that functionality. > > Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'. > This determines whether gdb will send it's environment to the target or > whether the target will inherit from the pdebug server. Cool, and I presume you can then read them back. In that case, (assuming the child inherits from the target side server), wouldn't you want LD_LIBRARY_PATH to be searched? If the linker-loader picks up libc from one place, but gdb picks it up from someplace else, you're hosed. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 20:10 ` Michael Snyder @ 2003-06-18 20:17 ` Kris Warkentin 0 siblings, 0 replies; 31+ messages in thread From: Kris Warkentin @ 2003-06-18 20:17 UTC (permalink / raw) To: Michael Snyder; +Cc: Kevin Buettner, Daniel Jacobowitz, Gdb@Sources.Redhat.Com > >>I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. > >>But come to think of it, do remote targets even have environment > >>variables? > > > >>And if so -- do they inherit them from gdb / the host? If there's a > >>gdbserver-type situation, and if the server is able to provide the true > >>environment variables from the target, then yes, we should use these. > >>But I don't recall any gdbserver ever offering that functionality. > > > > Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'. > > This determines whether gdb will send it's environment to the target or > > whether the target will inherit from the pdebug server. > > Cool, and I presume you can then read them back. > In that case, (assuming the child inherits from the target side server), > wouldn't you want LD_LIBRARY_PATH to be searched? If the linker-loader > picks up libc from one place, but gdb picks it up from someplace else, > you're hosed. Nope. Say I've got a windows host. My libs are in $QNX_TARGET/$CPU/usr/lib (ie. c:\QNXsdk\target\qnx6\ppcbe\usr\lib). On my target, LD_LIBRARY_PATH is relative to the root, on my host, they're relative to $QNX_TARGET/$CPU. This is where the target defined search function comes in. We construct a search path using $QNX_TARGET/$CPU as a base and search from there. Actually, we set solib-absolute-prefix to $QNX_TARGET/$CPU as well so in many cases it gets found by the very first check. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 18:52 ` Michael Snyder 2003-06-18 19:09 ` Kris Warkentin @ 2003-06-18 19:14 ` Daniel Jacobowitz 1 sibling, 0 replies; 31+ messages in thread From: Daniel Jacobowitz @ 2003-06-18 19:14 UTC (permalink / raw) To: Michael Snyder; +Cc: Kris Warkentin, Kevin Buettner, Gdb@Sources.Redhat.Com On Wed, Jun 18, 2003 at 11:50:45AM -0700, Michael Snyder wrote: > > * If available, use target defined search function. > > * Look in inferior's $PATH. > > * Look in inferior's $LD_LIBRARY_PATH. > > I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. > But come to think of it, do remote targets even have environment variables? > And if so -- do they inherit them from gdb / the host? If there's a > gdbserver-type situation, and if the server is able to provide the true > environment variables from the target, then yes, we should use these. > But I don't recall any gdbserver ever offering that functionality. None of the in-tree supported remote targets do. It's not in the current remote protocol as far as I know. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 12:11 ` Kris Warkentin 2003-06-18 15:07 ` Kris Warkentin @ 2003-06-18 18:45 ` Michael Snyder 1 sibling, 0 replies; 31+ messages in thread From: Michael Snyder @ 2003-06-18 18:45 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Daniel Jacobowitz, Gdb@Sources.Redhat.Com Kris Warkentin wrote: >>Given the fact that these tests are here, I don't think that the $PATH >>and $LD_LIBRARY_PATH checks are ever actually used for native >>debugging. >> >>After all, who bothers to set solib_search_path when doing native >>debugging? And if you do set solib_search_path, doesn't it seem >>strange that these additional checks suddenly become enabled? > > > Hmm...good point. It's probably completely unexercised code. > > >>So, at this point we have two choices: a) Do away with the $PATH and >>$LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove >>the ``solib_search_path != NULL'' check. >> >>If we can actually convince ourselves that leaving in the $PATH and >>$LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to >>go. At the moment, however, I'm strongly leaning towards option a. > > > Well, we had some customers complain that LD_LIBRARY_PATH stopped working > for them when they stopped setting solib-search-path. They were using it > for remote debugging (somewhat questionable I know) because they have a > central build server that stores most of their libs and then developers > systems have a mount. The administrators set LD_LIBRARY_PATH specifically > for gdb to find these libs when debugging remote targets. Well, that's obviously a kludge, not what they should be doing. We once discussed looking for an environment variable, eg. GDB_SOLIB_SEARCH_PATH, but somebody was against it (maybe Ian Lance Taylor?). Should we revive that idea? > They'll probably whine if I take it out. Too bad -- they're doing something wrong. > Really though, the only places I > can see this being useful is cases like this and when you've got a > misbehaving linker which doesn't fill in the full path. I don't think that is a sign of a misbehaving linker. Some libraries don't have the full path -- that's why there are two gdb variables rather than just one. >>In fact, for remote debugging, leaving these checks in is rather >>dangerous. If, for some reason, the shared lib is not found via >>either solib-absolute-prefix or solib-search-path, we don't want >>to search paths on the host file system which refer to the hosts >>libraries. If the file is found via one of these paths, it is >>almost certainly wrong, and I've seen cases where this can cause >>wildly unpredictable behavior. (E.g, segfaults on the target, or >>breakpoints being hit at strange places.) > > > This was my major problem with checking LD_LIBRARY_PATH. For cross-debugging, yes. I think it would always be wrong. >>I think I could be convinced to leave these checks in if we >>were to replace that ``solib_search_path != NULL'' conjunct with >>``solib_absolute_prefix == NULL'' instead. That is, if you set >>solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never >>be considered. (I guess there were actually three choices. We'll >>call this one option c.) > > > Well, that wouldn't help my customers since we do set solib-absolute-prefix. > On the other hand, there IS solib-search-path and .gdbinit files so I don't > really have a problem with telling them that the LD_L... checking has gone > away. I'll leave the decision to you. I'm just going to remove the > solib_search_path != NULL checks from our shipping version and mark the > behaviour as deprecated if necessary. > > cheers, > > Kris > > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 5:33 ` Kevin Buettner 2003-06-18 12:11 ` Kris Warkentin @ 2003-06-18 18:41 ` Michael Snyder 2003-06-18 19:16 ` Daniel Jacobowitz 1 sibling, 1 reply; 31+ messages in thread From: Michael Snyder @ 2003-06-18 18:41 UTC (permalink / raw) To: Kevin Buettner; +Cc: Kris Warkentin, Daniel Jacobowitz, Gdb@Sources.Redhat.Com Kevin Buettner wrote: > On Jun 17, 9:54pm, Kris Warkentin wrote: > > >>>>Michael, any comments? >>> >>>I don't remember. ;-( >>>I'll just remark that ld puts full paths in for some libs, and not for >> >>others. >> >>>That's why there are two variables, SOLIB-SEARCH-PATH and >>>SOLIB-ABSOLUTE-PREFIX. One is the prefix that goes before everything >>>(even rooted filespecs), and the other is the additional prefix that >>>goes before an un-rooted filespec. >> >>Okay then, here's what I propose. >> >>1) Change the order as Kevin suggested earlier. This give the user plenty >>of opportunity to tell gdb how to find the solibs before we thrash about >>desperately in LD_LIBRARY_PATH, etc. > > > Definitely okay. > > >>2) Take out the solib_search_path check in the if(found_file <0 && >>solib_search_path != NULL) parts of the last two desperation plays. I don't >>think there's any reason for them. > > > Wow. Good catch. I don't understand them either. But... > > >>I have a feeling that we want to leave the last two searches in place simply >>because native debugging is the most common and they probably catch a lot of >>action. Most people doing remote debugging are setting up their >>solib-absolute-prefix and such properly anyway. > > > Given the fact that these tests are here, I don't think that the $PATH > and $LD_LIBRARY_PATH checks are ever actually used for native > debugging. > > After all, who bothers to set solib_search_path when doing native > debugging? And if you do set solib_search_path, doesn't it seem > strange that these additional checks suddenly become enabled? > > So, at this point we have two choices: a) Do away with the $PATH and > $LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove > the ``solib_search_path != NULL'' check. > > If we can actually convince ourselves that leaving in the $PATH and > $LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to > go. At the moment, however, I'm strongly leaning towards option a. You don't think that gdb should honor LD_LIBRARY_PATH in native debugging, if it is set? Won't the linker-loader honor it? I'd be ready to agree that, if solib-search-path is set, it should override LD_LIBRARY_PATH. But if it isn't set... > In fact, for remote debugging, leaving these checks in is rather > dangerous. If, for some reason, the shared lib is not found via > either solib-absolute-prefix or solib-search-path, we don't want > to search paths on the host file system which refer to the hosts > libraries. If the file is found via one of these paths, it is > almost certainly wrong, and I've seen cases where this can cause > wildly unpredictable behavior. (E.g, segfaults on the target, or > breakpoints being hit at strange places.) Agreed. Indeed, I think LD_LIBRARY_PATH is required for native, and always wrong for cross. Is there any way we can use that distinction? Maybe with a configure variable? > I think I could be convinced to leave these checks in if we > were to replace that ``solib_search_path != NULL'' conjunct with > ``solib_absolute_prefix == NULL'' instead. That is, if you set > solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never > be considered. (I guess there were actually three choices. We'll > call this one option c.) > > Opinions? How about (d) a configure variable that enables the tests for native only. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 18:41 ` Michael Snyder @ 2003-06-18 19:16 ` Daniel Jacobowitz 2003-06-18 20:11 ` Michael Snyder 0 siblings, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2003-06-18 19:16 UTC (permalink / raw) To: Michael Snyder; +Cc: Kevin Buettner, Kris Warkentin, Gdb@Sources.Redhat.Com On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote: > You don't think that gdb should honor LD_LIBRARY_PATH in native > debugging, if it is set? Won't the linker-loader honor it? > > I'd be ready to agree that, if solib-search-path is set, > it should override LD_LIBRARY_PATH. But if it isn't set... As far as I'm concerned, the linker should always set the absolute pathname, and we shouldn't be doing any of this junk. I had to reimplement ELF search order a few months ago. It's considerably more complex then what we do here - DT_RPATH for example. > >In fact, for remote debugging, leaving these checks in is rather > >dangerous. If, for some reason, the shared lib is not found via > >either solib-absolute-prefix or solib-search-path, we don't want > >to search paths on the host file system which refer to the hosts > >libraries. If the file is found via one of these paths, it is > >almost certainly wrong, and I've seen cases where this can cause > >wildly unpredictable behavior. (E.g, segfaults on the target, or > >breakpoints being hit at strange places.) > > Agreed. Indeed, I think LD_LIBRARY_PATH is required for native, > and always wrong for cross. Is there any way we can use that > distinction? Maybe with a configure variable? No. Please take a look at PR gdb/633 and the discussion there. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 19:16 ` Daniel Jacobowitz @ 2003-06-18 20:11 ` Michael Snyder 2003-06-18 20:19 ` Kris Warkentin 2003-06-18 20:27 ` Daniel Jacobowitz 0 siblings, 2 replies; 31+ messages in thread From: Michael Snyder @ 2003-06-18 20:11 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Kevin Buettner, Kris Warkentin, Gdb@Sources.Redhat.Com Daniel Jacobowitz wrote: > On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote: > >>You don't think that gdb should honor LD_LIBRARY_PATH in native >>debugging, if it is set? Won't the linker-loader honor it? >> >>I'd be ready to agree that, if solib-search-path is set, >>it should override LD_LIBRARY_PATH. But if it isn't set... > > > As far as I'm concerned, the linker should always set the absolute > pathname, and we shouldn't be doing any of this junk. Well, but that is not in fact the case. For sure not on linux, and I don't think it is on solaris either. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 20:11 ` Michael Snyder @ 2003-06-18 20:19 ` Kris Warkentin 2003-06-18 20:27 ` Daniel Jacobowitz 1 sibling, 0 replies; 31+ messages in thread From: Kris Warkentin @ 2003-06-18 20:19 UTC (permalink / raw) To: Michael Snyder, Daniel Jacobowitz; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com > Daniel Jacobowitz wrote: > > On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote: > > > >>You don't think that gdb should honor LD_LIBRARY_PATH in native > >>debugging, if it is set? Won't the linker-loader honor it? > >> > >>I'd be ready to agree that, if solib-search-path is set, > >>it should override LD_LIBRARY_PATH. But if it isn't set... > > > > > > As far as I'm concerned, the linker should always set the absolute > > pathname, and we shouldn't be doing any of this junk. > > Well, but that is not in fact the case. For sure not on linux, > and I don't think it is on solaris either. Linkers can be funny that way. Things like the loader (in our case ldqnx.so) don't have the full path but other libs do. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 20:11 ` Michael Snyder 2003-06-18 20:19 ` Kris Warkentin @ 2003-06-18 20:27 ` Daniel Jacobowitz 2003-06-18 20:51 ` Michael Snyder 1 sibling, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2003-06-18 20:27 UTC (permalink / raw) To: Michael Snyder; +Cc: Kevin Buettner, Kris Warkentin, Gdb@Sources.Redhat.Com On Wed, Jun 18, 2003 at 01:11:38PM -0700, Michael Snyder wrote: > Daniel Jacobowitz wrote: > >On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote: > > > >>You don't think that gdb should honor LD_LIBRARY_PATH in native > >>debugging, if it is set? Won't the linker-loader honor it? > >> > >>I'd be ready to agree that, if solib-search-path is set, > >>it should override LD_LIBRARY_PATH. But if it isn't set... > > > > > >As far as I'm concerned, the linker should always set the absolute > >pathname, and we shouldn't be doing any of this junk. > > Well, but that is not in fact the case. For sure not on linux, > and I don't think it is on solaris either. In Linux it's the case for all searched-for objects, as far as I know - anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH, etc. will either be an absolute path or else contain slashes and be relative to the current directory. If it's not true for dlopen'd objects, well, there's no way to know where the app had chdir'd to when it loaded them. Do you know offhand when it's not true for GNU/Linux? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 20:27 ` Daniel Jacobowitz @ 2003-06-18 20:51 ` Michael Snyder 2003-06-19 12:24 ` Kris Warkentin 0 siblings, 1 reply; 31+ messages in thread From: Michael Snyder @ 2003-06-18 20:51 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Kevin Buettner, Kris Warkentin, Gdb@Sources.Redhat.Com Daniel Jacobowitz wrote: > On Wed, Jun 18, 2003 at 01:11:38PM -0700, Michael Snyder wrote: > >>Daniel Jacobowitz wrote: >> >>>On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote: >>> >>> >>>>You don't think that gdb should honor LD_LIBRARY_PATH in native >>>>debugging, if it is set? Won't the linker-loader honor it? >>>> >>>>I'd be ready to agree that, if solib-search-path is set, >>>>it should override LD_LIBRARY_PATH. But if it isn't set... >>> >>> >>>As far as I'm concerned, the linker should always set the absolute >>>pathname, and we shouldn't be doing any of this junk. >> >>Well, but that is not in fact the case. For sure not on linux, >>and I don't think it is on solaris either. > > > In Linux it's the case for all searched-for objects, as far as I know - > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH, > etc. will either be an absolute path or else contain slashes and be > relative to the current directory. If it's not true for dlopen'd > objects, well, there's no way to know where the app had chdir'd to when > it loaded them. > > Do you know offhand when it's not true for GNU/Linux? No, I just recall that, several years ago when I worked on this code, it was not always true. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-18 20:51 ` Michael Snyder @ 2003-06-19 12:24 ` Kris Warkentin 2003-06-19 23:33 ` Kevin Buettner 0 siblings, 1 reply; 31+ messages in thread From: Kris Warkentin @ 2003-06-19 12:24 UTC (permalink / raw) To: Michael Snyder, Daniel Jacobowitz; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com > > In Linux it's the case for all searched-for objects, as far as I know - > > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH, > > etc. will either be an absolute path or else contain slashes and be > > relative to the current directory. If it's not true for dlopen'd > > objects, well, there's no way to know where the app had chdir'd to when > > it loaded them. > > > > Do you know offhand when it's not true for GNU/Linux? > > No, I just recall that, several years ago when I worked on this code, > it was not always true. Okay gentlemen, all kidding aside, what do we do? At the bare minimum I believe the test /* If not found, next search the inferior's $PATH environment variable. */ if (found_file < 0 && solib_search_path != NULL) should be just: if (found_file < 0). We can always make a decision about removing the PATH and LD_LIBRARY_PATH checks later. cheers, Kris ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-19 12:24 ` Kris Warkentin @ 2003-06-19 23:33 ` Kevin Buettner 2003-06-20 0:02 ` Kevin Buettner 0 siblings, 1 reply; 31+ messages in thread From: Kevin Buettner @ 2003-06-19 23:33 UTC (permalink / raw) To: Kris Warkentin Cc: Michael Snyder, Daniel Jacobowitz, Gdb@Sources.Redhat.Com, Kevin Buettner On Jun 19, 8:24am, Kris Warkentin wrote: > > > In Linux it's the case for all searched-for objects, as far as I know - > > > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH, > > > etc. will either be an absolute path or else contain slashes and be > > > relative to the current directory. If it's not true for dlopen'd > > > objects, well, there's no way to know where the app had chdir'd to when > > > it loaded them. > > > > > > Do you know offhand when it's not true for GNU/Linux? > > > > No, I just recall that, several years ago when I worked on this code, > > it was not always true. > > Okay gentlemen, all kidding aside, what do we do? At the bare minimum I > believe the test > > /* If not found, next search the inferior's $PATH environment variable. */ > if (found_file < 0 && solib_search_path != NULL) > > should be just: > > if (found_file < 0). > > We can always make a decision about removing the PATH and LD_LIBRARY_PATH > checks later. Okay, I've come to a decision. It's still not clear to me if the PATH and LD_LIBRARY_PATH searches are needed for natives. Either they're not needed or nobody's noticed that some previously available functionality (prior to Nov 21, 2000) is now missing. I do know, however, that we definitely don't want to do these searches for (most) remote targets. In light of Michael's remarks, I'm now inclined to be more cautious about removing these searches than I was originally. Further, if you're debugging a remote target, you'd better have solib-absolute-prefix set, or things will almost certainly go wrong. To the best of my knowledge, when you're debugging a native target, you never set solib-absolute-prefix, so the fact that this is set or not gives us a cheap, but effective way to determine whether the intent is to run on a native target or not. Actually, it's better than that. Something that I occassionally do is to run against a "native" rda or gdb server where I don't set solib-absolute-prefix. Doing things in this fashion will make search algorithm for this kind of "remote" (which is really a native disguised as a remote) target identical to running a native and that is precisely what's desired. So... I'd like to see the checks preceding the PATH and LD_LIBRARY_PATH searches changed from: if (found_file < 0 && solib_search_path != NULL) to: if (found_file < 0 && solib_absolute_prefix == NULL) Kris, I believe you volunteered to make the necessary changes. Would you like to do the honors? BTW, your proposed comment changes look good too. Consider these changes preapproved, but do make sure you post the patch that you end up committing. Thanks, Kevin ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-19 23:33 ` Kevin Buettner @ 2003-06-20 0:02 ` Kevin Buettner 2003-06-20 12:28 ` Kris Warkentin 0 siblings, 1 reply; 31+ messages in thread From: Kevin Buettner @ 2003-06-20 0:02 UTC (permalink / raw) To: Kris Warkentin; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com, Michael Snyder On Jun 19, 4:16pm, Kevin Buettner wrote: > It's still not clear to me if the PATH and LD_LIBRARY_PATH searches > are needed for natives. Either they're not needed or nobody's noticed > that some previously available functionality (prior to Nov 21, 2000) > is now missing. I do know, however, that we definitely don't want to > do these searches for (most) remote targets. In light of Michael's > remarks, I'm now inclined to be more cautious about removing these > searches than I was originally. > > Further, if you're debugging a remote target, you'd better have > solib-absolute-prefix set, or things will almost certainly go wrong. > To the best of my knowledge, when you're debugging a native target, > you never set solib-absolute-prefix, so the fact that this is set or > not gives us a cheap, but effective way to determine whether the > intent is to run on a native target or not. > > Actually, it's better than that. Something that I occassionally do is > to run against a "native" rda or gdb server where I don't set > solib-absolute-prefix. Doing things in this fashion will make search > algorithm for this kind of "remote" (which is really a native > disguised as a remote) target identical to running a native and that > is precisely what's desired. I've just thought of another way to look at this which has nothing to do with inferences about which settings imply remote targets vs. which imply native targets. When you set solib-absolute-prefix, you want all absolute paths (aside from those constructed from solib-search-path) to be searched for using the given prefix. Our present search code using PATH and LD_LIBRARY_PATH does not honor solib-absolute-prefix for absolute paths, so it makes (some) sense to disable these searches when solib-absolute-prefix is set. It would probably make more sense to force the PATH and LD_LIBRARY_PATH searches to honor solib-absolute-prefix, but before we go down that road, I'd like to reach some definite conclusion regarding whether these searches are really necessary. Kevin ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-20 0:02 ` Kevin Buettner @ 2003-06-20 12:28 ` Kris Warkentin 2003-06-20 12:43 ` Kevin Buettner 0 siblings, 1 reply; 31+ messages in thread From: Kris Warkentin @ 2003-06-20 12:28 UTC (permalink / raw) To: Kevin Buettner; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com, Michael Snyder Doh....I read the first email, made the changes and submitted the patch before I saw this one. Oh well, it won't hurt to have that in there for now until we decide whether or not to prepend solib-absolute-prefix to paths. I'm personnally of the opinion that there is MORE than enough search capability there now. If someone can't find a lib between what the loader fills in, solib-search-path, solib-absolute-prefix AND target defined searches.... I mean, how much hand-holding do we want to do? The more you broaden your seach, the more likely you are to get something you don't want. cheers, Kris ----- Original Message ----- From: "Kevin Buettner" <kevinb@redhat.com> To: "Kris Warkentin" <kewarken@qnx.com> Cc: "Daniel Jacobowitz" <drow@mvista.com>; "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>; "Michael Snyder" <msnyder@redhat.com> Sent: Thursday, June 19, 2003 7:42 PM Subject: Re: Why does solib_open do what it does? > On Jun 19, 4:16pm, Kevin Buettner wrote: > > > It's still not clear to me if the PATH and LD_LIBRARY_PATH searches > > are needed for natives. Either they're not needed or nobody's noticed > > that some previously available functionality (prior to Nov 21, 2000) > > is now missing. I do know, however, that we definitely don't want to > > do these searches for (most) remote targets. In light of Michael's > > remarks, I'm now inclined to be more cautious about removing these > > searches than I was originally. > > > > Further, if you're debugging a remote target, you'd better have > > solib-absolute-prefix set, or things will almost certainly go wrong. > > To the best of my knowledge, when you're debugging a native target, > > you never set solib-absolute-prefix, so the fact that this is set or > > not gives us a cheap, but effective way to determine whether the > > intent is to run on a native target or not. > > > > Actually, it's better than that. Something that I occassionally do is > > to run against a "native" rda or gdb server where I don't set > > solib-absolute-prefix. Doing things in this fashion will make search > > algorithm for this kind of "remote" (which is really a native > > disguised as a remote) target identical to running a native and that > > is precisely what's desired. > > I've just thought of another way to look at this which has nothing to > do with inferences about which settings imply remote targets vs. > which imply native targets. > > When you set solib-absolute-prefix, you want all absolute paths (aside > from those constructed from solib-search-path) to be searched for > using the given prefix. Our present search code using PATH and > LD_LIBRARY_PATH does not honor solib-absolute-prefix for absolute > paths, so it makes (some) sense to disable these searches when > solib-absolute-prefix is set. > > It would probably make more sense to force the PATH and LD_LIBRARY_PATH > searches to honor solib-absolute-prefix, but before we go down that > road, I'd like to reach some definite conclusion regarding whether > these searches are really necessary. > > Kevin > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Why does solib_open do what it does? 2003-06-20 12:28 ` Kris Warkentin @ 2003-06-20 12:43 ` Kevin Buettner 0 siblings, 0 replies; 31+ messages in thread From: Kevin Buettner @ 2003-06-20 12:43 UTC (permalink / raw) To: Kris Warkentin, Kevin Buettner Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com, Michael Snyder On Jun 20, 8:28am, Kris Warkentin wrote: > Doh....I read the first email, made the changes and submitted the patch > before I saw this one. Oh well, it won't hurt to have that in there for now > until we decide whether or not to prepend solib-absolute-prefix to paths. Actually, you did the right thing. The fix that you committed will hold us until we figure out whether or not to retain the PATH / LD_LIBRARY_PATH searches. Kevin ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2003-06-20 12:43 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-17 19:01 Why does solib_open do what it does? Kris Warkentin 2003-06-17 19:13 ` Daniel Jacobowitz 2003-06-17 19:14 ` Kris Warkentin 2003-06-17 19:37 ` Elena Zannoni 2003-06-17 19:47 ` Kris Warkentin 2003-06-17 20:01 ` Kevin Buettner 2003-06-17 20:15 ` Kris Warkentin 2003-06-17 20:24 ` Kevin Buettner 2003-06-18 0:14 ` Michael Snyder 2003-06-18 1:43 ` Kris Warkentin 2003-06-18 5:33 ` Kevin Buettner 2003-06-18 12:11 ` Kris Warkentin 2003-06-18 15:07 ` Kris Warkentin 2003-06-18 18:52 ` Michael Snyder 2003-06-18 19:09 ` Kris Warkentin 2003-06-18 19:20 ` Andrew Cagney 2003-06-18 20:10 ` Michael Snyder 2003-06-18 20:17 ` Kris Warkentin 2003-06-18 19:14 ` Daniel Jacobowitz 2003-06-18 18:45 ` Michael Snyder 2003-06-18 18:41 ` Michael Snyder 2003-06-18 19:16 ` Daniel Jacobowitz 2003-06-18 20:11 ` Michael Snyder 2003-06-18 20:19 ` Kris Warkentin 2003-06-18 20:27 ` Daniel Jacobowitz 2003-06-18 20:51 ` Michael Snyder 2003-06-19 12:24 ` Kris Warkentin 2003-06-19 23:33 ` Kevin Buettner 2003-06-20 0:02 ` Kevin Buettner 2003-06-20 12:28 ` Kris Warkentin 2003-06-20 12:43 ` Kevin Buettner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).