* Problem with getExe and testInsertedBreakpoint @ 2007-07-26 13:23 Kris Van Hees 2007-07-26 13:58 ` Mark Wielaard 2007-07-26 15:00 ` Phil Muldoon 0 siblings, 2 replies; 12+ messages in thread From: Kris Van Hees @ 2007-07-26 13:23 UTC (permalink / raw) To: frysk Recently, a problem has surfaced related to getExe() in relation to core files and its use in the testInsertedBreakpoint() test. Specifically, the core file seems to store the first 79 characters of the full executable pathname only. This results in truncation in cases where the frysk build tree is located fairly far down a directory hierarchy (which is a implicit test in itself), and the testInsertedBreakpoint test tries to read the executable using a truncated (and thus invalid) executable path name. As far as the test is concerned, I think it might be easiest to simply use the (known) path name to the executable name directly because this particular test is *not* verifying whether the getExe() processing works. Avoiding this problem altogether in this test will at least avoid the current problem. Whether this problem can be resolved in general remains to be seen. If the executable name is simply not available, there is nothing we can do. However, there might be a tiny hope that we can get to the executable path name anyway. Running 'strings' on the core files I checked displays the untruncated version twice. I'm currently looking whether there is a clean, dependable way to get to that information. Cheers, Kris ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 13:23 Problem with getExe and testInsertedBreakpoint Kris Van Hees @ 2007-07-26 13:58 ` Mark Wielaard 2007-07-26 15:35 ` Phil Muldoon 2007-07-26 15:00 ` Phil Muldoon 1 sibling, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2007-07-26 13:58 UTC (permalink / raw) To: Kris Van Hees; +Cc: frysk [-- Attachment #1: Type: text/plain, Size: 2324 bytes --] Hi Kris, On Thu, 2007-07-26 at 06:23 -0700, Kris Van Hees wrote: > Recently, a problem has surfaced related to getExe() in relation to core > files and its use in the testInsertedBreakpoint() test. Specifically, > the core file seems to store the first 79 characters of the full > executable pathname only. This results in truncation in cases where the > frysk build tree is located fairly far down a directory hierarchy (which > is a implicit test in itself), and the testInsertedBreakpoint test tries > to read the executable using a truncated (and thus invalid) executable > path name. > > As far as the test is concerned, I think it might be easiest to simply > use the (known) path name to the executable name directly because this > particular test is *not* verifying whether the getExe() processing > works. Avoiding this problem altogether in this test will at least > avoid the current problem. Nice catch. But the test case seems to actually be testing the wrong thing. It should test the symbols found in the actual core file, but it tries to open Proc.getExe() which points to the (truncated) path of the executable that created the core file. > Whether this problem can be resolved in general remains to be seen. If > the executable name is simply not available, there is nothing we can do. > However, there might be a tiny hope that we can get to the executable > path name anyway. Running 'strings' on the core files I checked > displays the untruncated version twice. I'm currently looking whether > there is a clean, dependable way to get to that information. As pointed out earlier today in the fexe command thread it would be nice to split getExe() into 2 semantically different things. 1) String Proc.getExeName(); Which provides the possible name of the executable. Using /proc/pid/exe symlink following or the name stored in the core file. Both might not be completely accurate because they were truncated or moved. This should be used to display to the user what command was run. 2) File Proc.getExeFile(); Which provides the actual file path to open to get at the elf image (/proc/pid/exe opened "raw", not following the symlink, or the actual File that the core file was loaded from). Does that make sense/would that work? Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 13:58 ` Mark Wielaard @ 2007-07-26 15:35 ` Phil Muldoon 2007-07-26 18:57 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Phil Muldoon @ 2007-07-26 15:35 UTC (permalink / raw) To: Mark Wielaard; +Cc: Kris Van Hees, frysk Mark Wielaard wrote: > Hi Kris, > > On Thu, 2007-07-26 at 06:23 -0700, Kris Van Hees wrote: > >> Recently, a problem has surfaced related to getExe() in relation to core >> files and its use in the testInsertedBreakpoint() test. Specifically, >> the core file seems to store the first 79 characters of the full >> executable pathname only. This results in truncation in cases where the >> frysk build tree is located fairly far down a directory hierarchy (which >> is a implicit test in itself), and the testInsertedBreakpoint test tries >> to read the executable using a truncated (and thus invalid) executable >> path name. >> >> As far as the test is concerned, I think it might be easiest to simply >> use the (known) path name to the executable name directly because this >> particular test is *not* verifying whether the getExe() processing >> works. Avoiding this problem altogether in this test will at least >> avoid the current problem. >> > > Nice catch. But the test case seems to actually be testing the wrong > thing. It should test the symbols found in the actual core file, but it > tries to open Proc.getExe() which points to the (truncated) path of the > executable that created the core file. > > >> Whether this problem can be resolved in general remains to be seen. If >> the executable name is simply not available, there is nothing we can do. >> However, there might be a tiny hope that we can get to the executable >> path name anyway. Running 'strings' on the core files I checked >> displays the untruncated version twice. I'm currently looking whether >> there is a clean, dependable way to get to that information. >> > > As pointed out earlier today in the fexe command thread it would be nice > to split getExe() into 2 semantically different things. > > 1) String Proc.getExeName(); > Which provides the possible name of the executable. Using /proc/pid/exe > symlink following or the name stored in the core file. Both might not be > completely accurate because they were truncated or moved. This should be > used to display to the user what command was run. > 2) File Proc.getExeFile(); > Which provides the actual file path to open to get at the elf image > (/proc/pid/exe opened "raw", not following the symlink, or the actual > File that the core file was loaded from). > When a core file is modeled in Frysk, it could be a long time from when the core was created. An executable file might not be even available at that time. For this reason there are two layers of meta data built: 1) Basic meta-data. No executable available. No maps can be produced (but address ranges can). No solib tables can be built. No elided segment memory access. At this point we can model the information that is in the core file, and allow access to non-elided sections of the core file. This is basic inspection. Can't do much other than look at memory, and registers. 2) Enhanced meta-data. Executable is available. In this case we can find where the link-map was in the core file when it was dumped by looking at the executable's dynamic segment. We can build a table of what solibs were loaded and mapped into the process when it was dumped, and we can build a "rich" set of maps almost identical to what you would get in /proc/$$/maps. We can now allow elided memory access because we know what solib is at which address, so the host can open that solib and read that memory. This allows sophisticated operations as stack back traces, and so on. At no time is an executable ever loaded into memory during this process, or at any time. It's all simulated via CorefileByteBuffer, and dead/LinuxHost. The process might "look" alive from the interface, but it is well and truly, and probably forever will be, dead ;) All these operations are done by looking at the Elf image on disk. So relying on anything in /proc/$$ won't work in that instance. Hope that sheds a bit of light. Regards Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 15:35 ` Phil Muldoon @ 2007-07-26 18:57 ` Mark Wielaard 2007-07-26 19:32 ` Phil Muldoon 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2007-07-26 18:57 UTC (permalink / raw) To: Phil Muldoon; +Cc: Kris Van Hees, frysk [-- Attachment #1: Type: text/plain, Size: 2574 bytes --] Hi Phil, On Thu, 2007-07-26 at 10:34 -0500, Phil Muldoon wrote: > When a core file is modeled in Frysk, it could be a long time from when > the core was created. An executable file might not be even available at > that time. For this reason there are two layers of meta data built: > > 1) Basic meta-data. No executable available. No maps can be produced > (but address ranges can). No solib tables can be built. No elided > segment memory access. At this point we can model the information that > is in the core file, and allow access to non-elided sections of the core > file. This is basic inspection. Can't do much other than look at memory, > and registers. What does "elided" mean in this context? > 2) Enhanced meta-data. Executable is available. In this case we can find > where the link-map was in the core file when it was dumped by looking at > the executable's dynamic segment. We can build a table of what solibs > were loaded and mapped into the process when it was dumped, and we can > build a "rich" set of maps almost identical to what you would get in > /proc/$$/maps. We can now allow elided memory access because we know > what solib is at which address, so the host can open that solib and read > that memory. This allows sophisticated operations as stack back traces, > and so on. OK, so does this mean not all code segments might be available in the core elf file itself, but that you need to cross-reference them always against the actual executable (but you aren't guaranteed access to the orgininal executable since even the core file itself doesn't have a reliable link to it)? My question really is what about code segments that are modified (as we do in the testcase that Kris pointed at)? Or maybe more realistically, what about code segments generated dynamically by the process (like in the case of a just in time, hotspot, compiler)? Finally, how does the rest of the core get access to these code segments? For example in this testcase or in the DebugInfo, access to the Elf object for the Proc is obtained by doing new Elf(proc.getExe()). But since for core Procs that would give the (possible not full, or no longer existing) path to the original executable that seems the wrong approach. And from your explanation I now understand that you shouldn't do it this way (need to audit the code a bit more to find all cases where this happens), but go through the getMaps() interface and create a Dwfl from that. > Hope that sheds a bit of light. Yes, thanks! Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 18:57 ` Mark Wielaard @ 2007-07-26 19:32 ` Phil Muldoon 2007-07-27 10:00 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Phil Muldoon @ 2007-07-26 19:32 UTC (permalink / raw) To: Mark Wielaard; +Cc: Kris Van Hees, frysk Mark Wielaard wrote: > Hi Phil, > > On Thu, 2007-07-26 at 10:34 -0500, Phil Muldoon wrote: > > > What does "elided" mean in this context? > With apologies to Roland who coined and explained these terms to me. Any errors I make here are mine, but: elided means the segment is recorded in the program headers, but was not included in the core file dump (ie filesz = 0, memsz > 0). Segments are elided when they can be reconstructed after a core file dump (ie segments that have not been written to). included means both the program header and the segment itself is written (ie filesz >0, memsz >0 but filesz is never more than memsz) omitted means neither the program header entry or the segment is written for that segment (ie in future it will not exist in core file reconstruction). > >> 2) Enhanced meta-data. Executable is available. In this case we can find >> where the link-map was in the core file when it was dumped by looking at >> the executable's dynamic segment. We can build a table of what solibs >> were loaded and mapped into the process when it was dumped, and we can >> build a "rich" set of maps almost identical to what you would get in >> /proc/$$/maps. We can now allow elided memory access because we know >> what solib is at which address, so the host can open that solib and read >> that memory. This allows sophisticated operations as stack back traces, >> and so on. >> > > OK, so does this mean not all code segments might be available in the > core elf file itself, but that you need to cross-reference them always > against the actual executable (but you aren't guaranteed access to the > orgininal executable since even the core file itself doesn't have a > reliable link to it)? > Yes it means that though we might have the code executable segments in the core file, we lose the ability of basic navigation as _all the other executable segments_ might not be there, and certainly not in an easily readable/locatable way. That is why we need the executable for anything other than basic segment and note access, so we can find positional information (like the link_map). The only place the executable name is stored in the core file that we can get to reliably is in the elf_prpsinfo notes. > My question really is what about code segments that are modified (as we > do in the testcase that Kris pointed at)? Or maybe more realistically, > what about code segments generated dynamically by the process (like in > the case of a just in time, hotspot, compiler)? > They may or may not be there in the hot-spot case. If the segment has been written to, though, it will be included as it cannot be recreated post core dump. Essentially I suspect a core file of a Java process will be a core file of the JVM with one of the threads being the (user Java) program itself. > Finally, how does the rest of the core get access to these code > segments? For example in this testcase or in the DebugInfo, access to > the Elf object for the Proc is obtained by doing new Elf(proc.getExe()). > The core file code does not care one whit about how the user/implementor uses the information it provides. It cannot, and should not. It would be asking for safety checks beyond the api barrier. It simulates the process image _as close to it can_ to when that process was dumped. It is important to note that that this is still a lot of guessing and calculating and estimating - even if an executable is provided. If no executable was provided or found then that data is just not present in the first place. If you try to access elided data on a basic meta-data core file, it will throw a RuntimeException noting it cannot access that memory address. Proc.getExe() in a Corefile will return the executable string that was found in the notes. > But since for core Procs that would give the (possible not full, or no > longer existing) path to the original executable that seems the wrong > approach. It will provide the information it has. Because core files are traditionally associated with dead or dying processes, the level of paranoia when dealing with a core file should be appropriate. There can be any number of corrupt, badly written, busted, and generally misleading information in there. > And from your explanation I now understand that you shouldn't > do it this way (need to audit the code a bit more to find all cases > where this happens), but go through the getMaps() interface and create a > Dwfl from that. > Right, and I've talked a bit about this and learned that we should have done core files right from that start. Right now (or rather we had) code that makes assumptions that a process is alive and has entries in proc. As I find them, I correct them, or ask the author to correct them. The golden rule here is all information should always come from the Proc or the Task. In the case of maps, it should be getMaps(). In the case of memory, it should be via the Task's memory interface and so on. Hope that helps! Regards Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 19:32 ` Phil Muldoon @ 2007-07-27 10:00 ` Mark Wielaard 2007-07-27 13:41 ` Phil Muldoon 2007-07-27 19:04 ` Roland McGrath 0 siblings, 2 replies; 12+ messages in thread From: Mark Wielaard @ 2007-07-27 10:00 UTC (permalink / raw) To: Phil Muldoon; +Cc: Kris Van Hees, frysk [-- Attachment #1: Type: text/plain, Size: 3865 bytes --] Hi Phil, On Thu, 2007-07-26 at 14:32 -0500, Phil Muldoon wrote: > With apologies to Roland who coined and explained these terms to me. Any > errors I make here are mine, but: > > elided means the segment is recorded in the program headers, but was not > included in the core file dump (ie filesz = 0, memsz > 0). Segments are > elided when they can be reconstructed after a core file dump (ie > segments that have not been written to). > > included means both the program header and the segment itself is written > (ie filesz >0, memsz >0 but filesz is never more than memsz) > > omitted means neither the program header entry or the segment is written > for that segment (ie in future it will not exist in core file > reconstruction). Aha, that also explains the meaning of the new kernel /proc/sys sysctrl parameters fs.binfmt_elf.dumpwhole_segments to get all text sections included and fs.binfmt_elf.dump_elf_headers to get partial text sections that I saw Roland added. Does fcore have some similar parameters? > Yes it means that though we might have the code executable segments in > the core file, we lose the ability of basic navigation as _all the other > executable segments_ might not be there, and certainly not in an easily > readable/locatable way. That is why we need the executable for anything > other than basic segment and note access, so we can find positional > information (like the link_map). The only place the executable name is > stored in the core file that we can get to reliably is in the > elf_prpsinfo notes. Right, and elf_prpsinfo only allows for truncated executable names (16 chars). Bleah. So something like BuildID is really badly needed to present the user with something that is more often usable I guess. I saw that the BuildID support proposal was approved as one of the Fedora 8 Features: http://fedoraproject.org/wiki/Releases/FeatureBuildId http://fedoraproject.org/wiki/Releases/8/FeatureList Will it be possible for frysk to also support that in the Fedora 8 timeframe? > > My question really is what about code segments that are modified (as we > > do in the testcase that Kris pointed at)? Or maybe more realistically, > > what about code segments generated dynamically by the process (like in > > the case of a just in time, hotspot, compiler)? > > > > They may or may not be there in the hot-spot case. If the segment has > been written to, though, it will be included as it cannot be recreated > post core dump. OK, and I assume the same would be true for any code segments that were altered through ptrace poke? > > And from your explanation I now understand that you shouldn't > > do it this way (need to audit the code a bit more to find all cases > > where this happens), but go through the getMaps() interface and create a > > Dwfl from that. > > > Right, and I've talked a bit about this and learned that we should have > done core files right from that start. Right now (or rather we had) code > that makes assumptions that a process is alive and has entries in proc. > As I find them, I correct them, or ask the author to correct them. The > golden rule here is all information should always come from the Proc or > the Task. In the case of maps, it should be getMaps(). In the case of > memory, it should be via the Task's memory interface and so on. Thanks. I filed bug #4852 to clean up the code where I abused it and will go through the other stuff in the core listed there that uses the wrong approach (I know I just copied what I did from some other existing example, so it is good to get this fully cleaned up). > Hope that helps! It helped greatly. Thanks for sharing. Some of the things you said suddenly made me see the bigger picture and connect the dots. Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-27 10:00 ` Mark Wielaard @ 2007-07-27 13:41 ` Phil Muldoon 2007-07-27 19:04 ` Roland McGrath 1 sibling, 0 replies; 12+ messages in thread From: Phil Muldoon @ 2007-07-27 13:41 UTC (permalink / raw) To: Mark Wielaard; +Cc: Kris Van Hees, frysk Mark Wielaard wrote: > Hi Phil, > > On Thu, 2007-07-26 at 14:32 -0500, Phil Muldoon wrote: > > > Aha, that also explains the meaning of the new kernel /proc/sys sysctrl > parameters fs.binfmt_elf.dumpwhole_segments to get all text sections > included and fs.binfmt_elf.dump_elf_headers to get partial text sections > that I saw Roland added. Does fcore have some similar parameters? > > Yup, fcore -a dump all possible segments. However that is not the default. That has been there since fcore was written because I perhaps made the brave assumption that in userland core dumps we can hang around and dump more segments as the process is "fine". In kernel core dumps I think the aim it so do this all as quickly as possible and clobber the process. > Right, and elf_prpsinfo only allows for truncated executable names (16 > chars). Bleah. So something like BuildID is really badly needed to > present the user with something that is more often usable I guess. I saw > that the BuildID support proposal was approved as one of the Fedora 8 > Features: http://fedoraproject.org/wiki/Releases/FeatureBuildId > http://fedoraproject.org/wiki/Releases/8/FeatureList > Will it be possible for frysk to also support that in the Fedora 8 > timeframe? > > Given that there is a lot to do, and not enough of us to do it, I've taken the rather (perhaps cheeky) approach of letting Jan and Roland thrash out the details, then pick it up and incorporate it when done. I already owe a Roland an answer to the partially elided segment question and Frysk. > OK, and I assume the same would be true for any code segments that were > altered through ptrace poke? > > I'm not sure of kernel mechanics. The core dump class just looks at the the bits in /proc/$$/maps to see if it has been written to. > Thanks. I filed bug #4852 to clean up the code where I abused it and > will go through the other stuff in the core listed there that uses the > wrong approach (I know I just copied what I did from some other existing > example, so it is good to get this fully cleaned up). > > >> Hope that helps! >> > > It helped greatly. Thanks for sharing. Some of the things you said > suddenly made me see the bigger picture and connect the dots. > > Awesome, glad to be of help Regards Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-27 10:00 ` Mark Wielaard 2007-07-27 13:41 ` Phil Muldoon @ 2007-07-27 19:04 ` Roland McGrath 2007-07-31 9:57 ` Mark Wielaard 1 sibling, 1 reply; 12+ messages in thread From: Roland McGrath @ 2007-07-27 19:04 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk > Will it be possible for frysk to also support that in the Fedora 8 > timeframe? I intend to have some libdwfl additions for build-id before F8. Those will make it very easy to do something in Frysk. > OK, and I assume the same would be true for any code segments that were > altered through ptrace poke? Correct. The kernel's test is on its internal VM data structures, so it gets any private file mapping that has had some COW happen. Thanks, Roland ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-27 19:04 ` Roland McGrath @ 2007-07-31 9:57 ` Mark Wielaard 2007-07-31 10:18 ` Roland McGrath 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2007-07-31 9:57 UTC (permalink / raw) To: Roland McGrath; +Cc: frysk [-- Attachment #1: Type: text/plain, Size: 1083 bytes --] Hi Roland, On Fri, 2007-07-27 at 12:03 -0700, Roland McGrath wrote: > > Will it be possible for frysk to also support that in the Fedora 8 > > timeframe? > > I intend to have some libdwfl additions for build-id before F8. > Those will make it very easy to do something in Frysk. That would make it easy to fixup the core file consumer part in frysk indeed. But we would still need to make sure that when we produce core files we also include the BuildID. > > OK, and I assume the same would be true for any code segments that were > > altered through ptrace poke? > > Correct. The kernel's test is on its internal VM data structures, so it > gets any private file mapping that has had some COW happen. Nice to know. Somewhat related, is there some way to revert this? In the case of inserting low-level breakpoints all we really do is setting one instruction and then later resetting the original instruction. Is there any way to make the kernel know that the page can be remerged again because all writes to it have been reversed? Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-31 9:57 ` Mark Wielaard @ 2007-07-31 10:18 ` Roland McGrath 0 siblings, 0 replies; 12+ messages in thread From: Roland McGrath @ 2007-07-31 10:18 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk > But we would still need to make sure that when we produce core files we > also include the BuildID. What the changed kernel does is easy to replicate. When you otherwise would have elided a segment and it's a private mapping (...p in 2nd column of /proc/pid/maps) at offset 0 (3rd column), check if its contents begin with "\177ELF". If so, don't elide the first page of that segment. > Is there any way to make the kernel know that the page can > be remerged again because all writes to it have been reversed? No. This is one of the benefits that would come from the "fancy VM tricks" future item (don't bother asking for details, there aren't any). Thanks, Roland ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 13:23 Problem with getExe and testInsertedBreakpoint Kris Van Hees 2007-07-26 13:58 ` Mark Wielaard @ 2007-07-26 15:00 ` Phil Muldoon 2007-07-26 15:03 ` Phil Muldoon 1 sibling, 1 reply; 12+ messages in thread From: Phil Muldoon @ 2007-07-26 15:00 UTC (permalink / raw) To: Kris Van Hees; +Cc: frysk Kris Van Hees wrote: > Recently, a problem has surfaced related to getExe() in relation to core > files and its use in the testInsertedBreakpoint() test. Specifically, > the core file seems to store the first 79 characters of the full > executable pathname only. For context here. The executable name is usually stored in two places, both in the same note: eu-readelf -n core.2843 Note segment of 584 bytes at offset 0x294: Owner Data size Type CORE 124 PRPSINFO state: T (84), zombie: 49, nice: 48 flags: 00400000, uid: 500, gid: 500 pid: 2843, ppid: 2807, pgrp: 2843, sid: 2807 fname: funit-child args: /home/pmuldoon/frysk_bin/frysk-core/frysk/pkglibdir/funit-child 10000 --busy-lo The first is fname, and the second ... assuming no tinkering with the args, is arg[0] in the args list. In the struct elf_prpsinfo, these two are defined as char pr_fname[16]; /* Filename of executable */ char pr_psargs[80]; /* Initial part of arg list */ So the length is limited in the notes section in the core file. There is nothing fcore, or gcore can do to overcome this. The fcore command uses automatic executable location, which tries to find the executable from arg[0], or /usr/bin, or /bin. This is because there are two constructors in dead/LinuxHost. One that just takes just a core file and tries to find the core file itself (with hopefully build-id patches in the future), and one that takes a core file and its corresponding executable. From an api point of view, the latter will always be more accurate. Perhaps fcore and other core file utilities need to utilize the second constructor? Personally I would prefer this approach. > This results in truncation in cases where the > frysk build tree is located fairly far down a directory hierarchy (which > is a implicit test in itself), and the testInsertedBreakpoint test tries > to read the executable using a truncated (and thus invalid) executable > path name. > The truncation is always going to occur in that case :( > As far as the test is concerned, I think it might be easiest to simply > use the (known) path name to the executable name directly because this > particular test is *not* verifying whether the getExe() processing > works. Avoiding this problem altogether in this test will at least > avoid the current problem. > The second constructor in dead/LinuxHost will satisfy that. Anyway, good catch. Regards Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Problem with getExe and testInsertedBreakpoint 2007-07-26 15:00 ` Phil Muldoon @ 2007-07-26 15:03 ` Phil Muldoon 0 siblings, 0 replies; 12+ messages in thread From: Phil Muldoon @ 2007-07-26 15:03 UTC (permalink / raw) To: Kris Van Hees; +Cc: frysk Phil Muldoon wrote: > Perhaps fcore and other core file utilities need to utilize the second > constructor? Sorry made a mistake here. fcore should be fstack, fhpd, and source window. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-07-31 10:18 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-07-26 13:23 Problem with getExe and testInsertedBreakpoint Kris Van Hees 2007-07-26 13:58 ` Mark Wielaard 2007-07-26 15:35 ` Phil Muldoon 2007-07-26 18:57 ` Mark Wielaard 2007-07-26 19:32 ` Phil Muldoon 2007-07-27 10:00 ` Mark Wielaard 2007-07-27 13:41 ` Phil Muldoon 2007-07-27 19:04 ` Roland McGrath 2007-07-31 9:57 ` Mark Wielaard 2007-07-31 10:18 ` Roland McGrath 2007-07-26 15:00 ` Phil Muldoon 2007-07-26 15:03 ` Phil Muldoon
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).