Hi Can anyone help me in finding the offset of a particular instruction in a function, please? Thnks in advance. Sai -- This message posted from opensolaris.org
sai praneeth kanuri wrote:> Hi > > Can anyone help me in finding the offset of a particular instruction > in a function, please?please be a bit more specific: I''m assuming you''re talking about C code and a specific C instruction, the offset of which you want to find in the disassembly in order to instrument it, is that right? If so: I usually go about this with mdb and do: <functionname>::dis and then it''s up to you to match up the machine instructions with the C code ... if this is on x86, the "crashdump analysis" book you can find here: http://www.opensolaris.org/os/community/documentation/doc_index/dev/ is a very helpful document. HTH Michael -- Michael Schuster Sun Microsystems, Inc. recursion, n: see ''recursion''
Hi, Actually i want to enable a probe at a particular instruction in a function (C or C++ program on sparc machine). For the same, i need the offset for mentioning in the probe. Thanks!! On 8/17/07, michael schuster <Michael.Schuster at sun.com> wrote:> > sai praneeth kanuri wrote: > > Hi > > > > Can anyone help me in finding the offset of a particular instruction > > in a function, please? > > please be a bit more specific: I''m assuming you''re talking about C code > and a specific C instruction, the offset of which you want to find in > the disassembly in order to instrument it, is that right? > > If so: I usually go about this with mdb and do: > > <functionname>::dis > > and then it''s up to you to match up the machine instructions with the C > code ... > > if this is on x86, the "crashdump analysis" book you can find here: > http://www.opensolaris.org/os/community/documentation/doc_index/dev/ > is a very helpful document. > > HTH > Michael > -- > Michael Schuster Sun Microsystems, Inc. > recursion, n: see ''recursion'' >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070817/6fb315c9/attachment.html>
sai praneeth kanuri wrote:> Hi, > > Actually i want to enable a probe at a particular instruction in a > function (C or C++ program on sparc machine). > > For the same, i need the offset for mentioning in the probe.and that''s why you need to do what I described - I don''t know of a simpler way (I''d welcome it if someone knows :-). Michael PS: perhaps some more information will help: the mapping from C to assembly is not 1:1, but in most cases, 1:N (N > 1); the exact details depend on the compiler and the options (optimisation!) used, etc, therefore it is necessary to look at the (dis)assembly.> > Thanks!! > > On 8/17/07, *michael schuster* <Michael.Schuster at sun.com > <mailto:Michael.Schuster at sun.com>> wrote: > > sai praneeth kanuri wrote: > > Hi > > > > Can anyone help me in finding the offset of a particular instruction > > in a function, please? > > please be a bit more specific: I''m assuming you''re talking about C code > and a specific C instruction, the offset of which you want to find in > the disassembly in order to instrument it, is that right? > > If so: I usually go about this with mdb and do: > > <functionname>::dis > > and then it''s up to you to match up the machine instructions with the C > code ... > > if this is on x86, the "crashdump analysis" book you can find here: > http://www.opensolaris.org/os/community/documentation/doc_index/dev/ > is a very helpful document. > > HTH > Michael > -- > Michael Schuster Sun Microsystems, Inc. > recursion, n: see ''recursion'' > >-- Michael Schuster Sun Microsystems, Inc. recursion, n: see ''recursion''
I find it exceedingly annoying that there is no easy way to figure out the correct instruction offsets needed by dtrace from the source and object files. You can find the generated assembler output by using the -S option to the compiler. This relates the source lines to the assembly instructions, but it does not give the offsets. You can use the dis command to find the offset relative to function addresses, but it does not show the corresponding source lines, and because many assembler instructions are actually pseudo instructions, it is often very difficult to relate use the assembler file to figure out the line numbers. Also, symbols are not shown symbolically. You can use dbx or mdb; these printout the actual addresses you need as well as the symbols, but you still have the problem of the instructions not matching, and of course you have the extra work of running the program with the debugger. It wouldn''t be so bad if I knew that it couldn''t be done, that the information needed isn''t available at some stage, but dammit, dbx does it when you assign a breakpoint. If the info is available to dbx, why can''t we get dis to do it as well? Or enhance -S to include the offsets. Or enhance the assembler to produce modified source output as well as offsets in a listing? michael schuster wrote:> sai praneeth kanuri wrote: >> Hi, >> >> Actually i want to enable a probe at a particular instruction in a >> function (C or C++ program on sparc machine). >> >> For the same, i need the offset for mentioning in the probe. > > and that''s why you need to do what I described - I don''t know of a > simpler way (I''d welcome it if someone knows :-). > > Michael > > PS: perhaps some more information will help: the mapping from C to > assembly is not 1:1, but in most cases, 1:N (N > 1); the exact details > depend on the compiler and the options (optimisation!) used, etc, > therefore it is necessary to look at the (dis)assembly. > >> Thanks!! >> >> On 8/17/07, *michael schuster* <Michael.Schuster at sun.com >> <mailto:Michael.Schuster at sun.com>> wrote: >> >> sai praneeth kanuri wrote: >> > Hi >> > >> > Can anyone help me in finding the offset of a particular instruction >> > in a function, please? >> >> please be a bit more specific: I''m assuming you''re talking about C code >> and a specific C instruction, the offset of which you want to find in >> the disassembly in order to instrument it, is that right? >> >> If so: I usually go about this with mdb and do: >> >> <functionname>::dis >> >> and then it''s up to you to match up the machine instructions with the C >> code ... >> >> if this is on x86, the "crashdump analysis" book you can find here: >> http://www.opensolaris.org/os/community/documentation/doc_index/dev/ >> is a very helpful document. >> >> HTH >> Michael >> -- >> Michael Schuster Sun Microsystems, Inc. >> recursion, n: see ''recursion'' >> >> > >-- blu Screening ideas are indeed thought up by the Office for Annoying Air Travelers and vetted through the Directorate for Confusion and Complexity - Kip Hawley, Head of the TSA ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
Brian Utterback wrote:> I find it exceedingly annoying that there is no easy way to figure > out the correct instruction offsets needed by dtrace from the > source and object files. > > You can find the generated assembler output by using the -S > option to the compiler. This relates the source lines to the > assembly instructions, but it does not give the offsets. > You can use the dis command to find the offset relative to > function addresses, but it does not show the corresponding > source lines, and because many assembler instructions are > actually pseudo instructions, it is often very difficult > to relate use the assembler file to figure out the line > numbers. Also, symbols are not shown symbolically. > You can use dbx or mdb; these printout the actual addresses > you need as well as the symbols, but you still have the > problem of the instructions not matching, and of course you > have the extra work of running the program with the debugger. > > It wouldn''t be so bad if I knew that it couldn''t be done, that > the information needed isn''t available at some stage, but dammit, > dbx does it when you assign a breakpoint. If the info is available > to dbx, why can''t we get dis to do it as well? Or enhance -S toSorry, it might be I didn''t undestand you but how could you set a breakpoint in dbx if you don''t know the exact address? Or are speaking about the case when a debug info is available and the breakpoint is like "stop at <line>"? The latter case will require DTrace to handle DWARF (at least the subset of it regarding the line number information) which is something I don''t believe to happen (any time soon?).> include the offsets. Or enhance the assembler to produce modified > source output as well as offsets in a listing?This is an interesting question. I cc''ed it to Alfred Huang who could say something regarding x86 assembler.> > michael schuster wrote: >> sai praneeth kanuri wrote: >>> Hi, >>> >>> Actually i want to enable a probe at a particular instruction in a >>> function (C or C++ program on sparc machine). >>> >>> For the same, i need the offset for mentioning in the probe. >> and that''s why you need to do what I described - I don''t know of a >> simpler way (I''d welcome it if someone knows :-). >> >> Michael >> >> PS: perhaps some more information will help: the mapping from C to >> assembly is not 1:1, but in most cases, 1:N (N > 1); the exact details >> depend on the compiler and the options (optimisation!) used, etc, >> therefore it is necessary to look at the (dis)assembly. >> >>> Thanks!! >>> >>> On 8/17/07, *michael schuster* <Michael.Schuster at sun.com >>> <mailto:Michael.Schuster at sun.com>> wrote: >>> >>> sai praneeth kanuri wrote: >>> > Hi >>> > >>> > Can anyone help me in finding the offset of a particular instruction >>> > in a function, please? >>> >>> please be a bit more specific: I''m assuming you''re talking about C code >>> and a specific C instruction, the offset of which you want to find in >>> the disassembly in order to instrument it, is that right? >>> >>> If so: I usually go about this with mdb and do: >>> >>> <functionname>::dis >>> >>> and then it''s up to you to match up the machine instructions with the C >>> code ... >>> >>> if this is on x86, the "crashdump analysis" book you can find here: >>> http://www.opensolaris.org/os/community/documentation/doc_index/dev/ >>> is a very helpful document. >>> >>> HTH >>> Michael >>> -- >>> Michael Schuster Sun Microsystems, Inc. >>> recursion, n: see ''recursion'' >>> >>> >> >-- Anton
"Brian" == Brian Utterback <Brian.Utterback at Sun.COM> writes: Brian> I find it exceedingly annoying that there is no easy way to figure Brian> out the correct instruction offsets needed by dtrace from the Brian> source and object files. Brian> You can find the generated assembler output by using the -S Brian> option to the compiler. This relates the source lines to the Brian> assembly instructions, but it does not give the offsets. It does for SPARC. For whatever reason, it does not for x86 (at least in my experience). Seems like this could be an RFE (I might consider it a bug) against the x86 code generator. -- Dave Marquardt Sun Microsystems, Inc. Austin, TX +1 512 401-1077 (SUN internal: x64077)
Dave Marquardt wrote:> "Brian" == Brian Utterback <Brian.Utterback at Sun.COM> writes: > > Brian> I find it exceedingly annoying that there is no easy way to figure > Brian> out the correct instruction offsets needed by dtrace from the > Brian> source and object files. > > Brian> You can find the generated assembler output by using the -S > Brian> option to the compiler. This relates the source lines to the > Brian> assembly instructions, but it does not give the offsets. > > It does for SPARC. For whatever reason, it does not for x86 (at leastDoes it? It is intermixing source lines with assembler which is better that x86 where there is no source lines at all. Still the offsets (or just addresses) are not there...> in my experience). Seems like this could be an RFE (I might consider > it a bug) against the x86 code generator.Feel free to file it. :) -- Anton
Nope, didn''t give me the offset on SPARC either. Anton: Yes, you are right, I was referring to the case where you say "stop at line" in dbx. However, while it would be great if DTrace could do this itself, I have no problem with using a tool to get the offsets. Mostly I want a way to find the offset given a line number, even if there is a manual step such as "add this offset to the address of ''main''". Anton Youdkevitch wrote:> Dave Marquardt wrote: >> "Brian" == Brian Utterback <Brian.Utterback at Sun.COM> writes: >> >> Brian> I find it exceedingly annoying that there is no easy way to figure >> Brian> out the correct instruction offsets needed by dtrace from the >> Brian> source and object files. >> >> Brian> You can find the generated assembler output by using the -S >> Brian> option to the compiler. This relates the source lines to the >> Brian> assembly instructions, but it does not give the offsets. >> >> It does for SPARC. For whatever reason, it does not for x86 (at least > Does it? It is intermixing source lines with assembler which is better > that x86 where there is no source lines at all. Still the offsets (or > just addresses) are not there... > >> in my experience). Seems like this could be an RFE (I might consider >> it a bug) against the x86 code generator. > Feel free to file it. :) >-- blu Screening ideas are indeed thought up by the Office for Annoying Air Travelers and vetted through the Directorate for Confusion and Complexity - Kip Hawley, Head of the TSA ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
Brian, Friday, August 17, 2007, 7:36:06 PM, you wrote:> Nope, didn''t give me the offset on SPARC either.> Anton: Yes, you are right, I was referring to the case where > you say "stop at line" in dbx. However, while it would be great > if DTrace could do this itself, I have no problem with using a > tool to get the offsets. Mostly I want a way to find the offset > given a line number, even if there is a manual step such as > "add this offset to the address of ''main''".There is no easy way to do it, I''m afraid. Those "line number to offset" mappings is stored in DWARF format. There is a dwarfdump utility, however, that can give your the mappings. I''m not sure about the ease of parsing the output, though...> Anton Youdkevitch wrote: >> Dave Marquardt wrote: >>> "Brian" == Brian Utterback <Brian.Utterback at Sun.COM> writes: >>> >>> Brian> I find it exceedingly annoying that there is no easy way to figure >>> Brian> out the correct instruction offsets needed by dtrace from the >>> Brian> source and object files. >>> >>> Brian> You can find the generated assembler output by using the -S >>> Brian> option to the compiler. This relates the source lines to the >>> Brian> assembly instructions, but it does not give the offsets. >>> >>> It does for SPARC. For whatever reason, it does not for x86 (at least >> Does it? It is intermixing source lines with assembler which is better >> that x86 where there is no source lines at all. Still the offsets (or >> just addresses) are not there... >> >>> in my experience). Seems like this could be an RFE (I might consider >>> it a bug) against the x86 code generator. >> Feel free to file it. :) >>
Quoth Anton Youdkevitch on Fri, Aug 17, 2007 at 08:50:03PM +0400:> There is no easy way to do it, I''m afraid. Those "line number to > offset" mappings is stored in DWARF format. There is a dwarfdump > utility, however, that can give your the mappings. I''m not sure about > the ease of parsing the output, though...There is also /usr/sfw/bin/gaddr2line though I suppose it does the opposite of what the thread initator wanted. And I hear that it works with gcc and Studio 12, but Studio 11 generates DWARF which confuses it. David