On Monday, June 6, 2022 at 12:02:42 PM UTC-7, Randall wrote:
> On Monday, June 6, 2022 at 1:09:32 p.m. UTC-4, rkd...@gmail.com wrote:
> > On Monday, June 6, 2022 at 8:01:31 AM UTC-7, s4n...@gmail.com wrote:
> > > On Monday, June 6, 2022 at 12:02:52 AM UTC+3, Randall wrote:
> > > > On Saturday, June 4, 2022 at 3:35:33 p.m. UTC-4, rkd...@gmail.com wrote:
> > > > > On Saturday, June 4, 2022 at 11:47:35 AM UTC-7, s4n...@gmail.com wrote:
> > > > > > On Tuesday, May 24, 2022 at 11:50:02 AM UTC+3, rkd...@gmail.com wrote:
> > > > > > > On Monday, May 23, 2022 at 9:15:05 PM UTC-7, red floyd wrote:
> > > > > > > > On 5/23/2022 11:09 AM, Andre White wrote:
> > > > > > > > > On Monday, May 23, 2022 at 5:28:35 PM UTC+3, red floyd wrote:
> > > > > > > > >> On 5/22/2022 2:26 PM, Andre White wrote:
> > > > > > > > >>> Need help,
> > > > > > > > >>> How to re-linking runnable object with new library using ELD..
> > > > > > > > >>>
> > > > > > > > >>> Thanks
> > > > > > > > >> User library, or DLL?
> > > > > > > > >>
> > > > > > > > >> User library:
> > > > > > > > >>
> > > > > > > > >> eld -change libname $vol.subvol.lib exefile
> > > > > > > > >>
> > > > > > > > >> I don't think it's possible for a DLL.
> > > > > > > > > Is DLL (Loadfile).
> > > > > > > > I don't think it's possible, and I've looked for ways to do it.
> > > > > > > > -alf doesn't work, nor any other method I've tried.
> > > > > > > This is a bit awkward to use, so it might not be a good solution for your situation.
> > > > > > >
> > > > > > > If the new DLL has the same name as the one you want to replace, you can use the DEFINEs or environment variables with names =_RLD_LIB_PATH or =_RLD_FIRST_LIB_PATH to make the loader look first in the location where the new DLL is located before it looks in the location where the original DLL is located. See the DLL Programmer's Guide for the explanation of those DEFINEs and environment variables.
> > > > > > >
> > > > > > > If the new library has a different name, you can create a DLL of your own with the same name as that of the original DLL, have it reexport the symbols of the new DLL, then use =_RLD_LIB_PATH or =_RLD_FIRST_LIB_PATH to get the loader to look in the location of the DLL you created before it looks where the original DLL is located. When the loader loads your DLL, it will also load all the symbols from the new DLL and use them to satisfy the references that the original DLL would have been used to satisfy.
> > > > > > >
> > > > > > > If there is priv code and/or licensed code involved anywhere in the program, there are extra security constraints I don't completely understand, but they might prevent the above approach from working. (I believe the extra constraints are needed to prevent a malicious user from using the substitution mechanism to run his code in priv mode.)
> > > > > > >
> > > > > > > If you want to try this, but have trouble understanding the explanations in the DLL Programmer's Guide, post your questions and someone here might be able to help.
> > > > > > Thanks for your input.
> > > > > >
> > > > > > I'm trying to debug on BASE24-EPS related Heap corruption/Memory leaks. What I read from Debugging Dynamic Memory, I need to Invoke Native Inspect with the lib zrtcdll/xrtcdll (to enable memory-debugging support).
> > > > > > The problem is, whatever object related with ACI product I need to run with library from ACI (XNLIBN). So, during I'm type "set heap-check on" I will get an error "xrtcdll/zrtcdll library not found".
> > > > > I don't know anything about the debugging dynamic memory thing you mention, but my first impression is that the suggestion I gave above is not relevant to the problem you are having with that.
> > > > >
> > > > > My guess, and it is just a guess, is that you either need to modify the native inspect executable file to add the "lib xrtcdll" attribute to it, or you need to run xinspect with the option /lib xrtcdll/ and use the attach command in xinspect to get xinspect to take control of the Base24 process you want to debug. But this is just a guess based on not understanding the xinspect feature you are trying to use, so I could be WAY off base.
> > > > The run -lib option might work, or from Guardian /lib/. Otherwise, I do not think you can relink this easily - it might be possible. You could open a GNSC case.
> > > Hi Randall,
> > >
> > > If I'm running using /lib/, I must invoke 2 library. First library from ACI (Mandatory), and second library for xrtcdll. But is not possible running 2 library at the same time.
> > You would only have to specify two libraries at the same time if the xrtcdll library contains functions that must be callable by some code that xinspect inserts into the executable that you are trying to debug. Or maybe xrtcdll provides functions that are replacements for malloc(), free(), and similar memory allocation functions. I do not know how that memory debugging function of xinspect works. Maybe it works that way, maybe not.
> >
> > If it works by inserting regular debug traps into the executable begin debugged, then the xinspect code calls the functions in the xrtcdll library, then you would only need to specify the xrtcdll library when the xinspect executable gets started. In that case, you would have to start xinspect with the /lib xrtcdll/ option yourself (not rely on the OS starting it automatically for you), then grab control of the process you want to debug using the xinspect command that I believe is named "attach". (or maybe there is a command in xinspect that starts a process to be debugged from within xinspect -- I don't know xinspect very well)
> >
> > If the xrtcdll library must be in the address space of the process being debugged, and that process already depends on a user library of its own, I don't know a way to make that work. (That doesn't mean there is no way -- just that if there is a way, I don't know it.) In the original Tandem code 100 object file format, there was no difference between executable and linkable files, so you could combine two library files to produce a combined library that included both sets of functions. In the native code world, we have the disimprovement that linkable and loadable files are not the same.
> >
> > If xrtcdll provides functions that must be used in place of functions in the regular system library such as malloc(), free(), etc., then maybe (just maybe -- I don't know for sure) it might work to specify the location of the xrtcdll library using the =_RLD_FIRST_LIB_PATH DEFINE to get those functions to load from xrtcdll instead of from the normal place. If that is the way to get it to work, then if that is not described in the manual that discusses this special memory debugging, the manual should be updated (but again, I don't know that will work.)
> AFAIK: xinspect does not actually replace the calls, but sets virtual breakpoints and then invokes the methods in the DLL. Why this cannot be done dynamically...<shrug>. The heap check does not work if the program redirects malloc and/or free.

I just looked at zrtcdll on an H-series system and xrtcdll on an L-series system. Both export functions such as malloc, free, strcat, memcpy, and also a boatload of functions whose names begin with __rtc.

I think this means that the DLL does replace the memory management functions and provides a bunch of other code that xinspect uses. So it looks like it cannot work correctly if just used as a user library for xinspect. Since the Base24 program has a user library of its own that it apparently needs, you cannot specify xrtcdll in place of the Base24-provided user library.

The only way I can think of that might get the special debugging to work would be to use the =_RLD_FIRST_LIB_PATH DEFiNE before starting Base24 to specify the subvolume which contains xrtcdll (it was the current SYSnn subvolume on the two systems I looked at). I think that has a good chance of getting the calls of the memory management functions from the Base24 code to be satisfied by the versions of those functions in xrtcdll. I am not sure whether the calls from the user library will be satisfied from the =_RLD_FIRST_LIB_PATH location or not. I'm too lazy to look up the rules for satisfying function call references in the DLL manual to see whether =_RLD_FIRST_LIB_PATH is effective for calls from the user library or not. I think it should be, but I don't know for sure.

The manual that describes this special memory debugging does explicitly say that it cannot be used if the program to be debugged already uses a user library of its own. The manual also does not mention using the =_RLD_FIRST_LIB_PATH DEFINE. I have a feeling that, even if the approach using =_RLD_FIRST_LIB_PATH I described would work, neither the writer of the manual nor the developer of the special memory debugging would have thought of it. I think there is enough of a chance that using =_RLD_FIRST_LIB_PATH as I described will work that it is worth the, I assume, small effort it would take to try it.

Of course, there is a lot I don't know, or might not be remembering at the moment, so it easily could be that there is some obvious reason the approach using =_RLD_FIRST_LIB_PATH won't work, but if I needed to use that special memory debugging feature on a program that used its own user library, I'd certainly give the approach using =_RLD_FIRST_LIB_PATH a try.