Closed pinki closed 6 years ago
Hello, it would indeed be great, but taking into account that DWARF specification is rather large:
What do you think?
For me, it would be enought, if the dwarf part covers the extraction of global variables (name, address, value, type and array information (if it's an array)) and specific type information (name, base type, size, signed or unsigned, the struct's/union's structure, maybe enum values).
And maybe some information, that's gettable while parsing the info above.
I see. Well, I guess that could be good approach - do some stubs, then extend the API as needed by users. Would you like to participate, at least once the basic code would be there?
I'd like to participate, but I've no idea how the dwarf's structure looks like. :/ But I'd like to try. I hope to find the required information.
I will probably start doing some work next month (maybe sooner if it will be possible). I'll also push some informations about what work could be helpful where etc. Stay tuned ;)
That would be great, thanks. I'm currently trying to port the eclipse project's dwarf reader from java to c#, but I have some errors with reasons that are hard to detect. If you want to have a look I could send it to you.
Konrad,
Sorry for this late reply, we have been really busy trying to get a demo ready for mid-November.
I am not sure of how much help I can be, I am not fluent in either Java or c#. If I program on Windows it is mostly VB.
Apart from that I will also be a little busy until late November. But, I will definitely keep an eye on your project and maybe we can catch up again before the years end!
Anyway, my best regards,
Natie.
On Fri, Sep 6, 2013 at 1:33 PM, pinki notifications@github.com wrote:
That would be great, thanks. I'm currently trying to port the eclipse project's dwarf reader from java to c#, but I have some errors with reasons that are hard to detect. If you want to have a look I could send it to you.
— Reply to this email directly or view it on GitHubhttps://github.com/konrad-kruczynski/elfsharp/issues/13#issuecomment-23933988 .
+1
Similar to what you get if you type ptype YourVariable
in gdb, it would be awesome to be able to first extract all variables (in my case the global ones) and then the corresponding type definitions. I have a lot of nested structs and would like to build a complete tree in my application.
E.g. for a single level typedef struct applied to variable Temp_Data
.
(gdb) ptype Temp_Data
type = volatile struct {
S16 Igbt_deg_S16;
S16 Motor_deg_S16;
S16 Pcb_deg_S16;
S16 Cpu_deg_S16;
}
I see. Naturally, extracting only globals' names is possible even now, just with a list of symbols. Going further needs some coding and, as you can see, my expectations about free time I could spend on this task were not met. @csholmq Do you plan to work on this? If that's the case, I could probably do some initial work, like getting the DWARF data from ELF, parsing some headers etc.
That would be great. I need to get familiar with both the ELF format and your codebase. So if you could do some basic extraction and parsing of the Dwarf data that would be super and I could probably take it a bit further.
OK, I'll try to do it as soon as possible (which won't be very soon ;)). The codebase is, frankly, quite dated but the only interesting part from your point of view will probably be the part that extracts DWARF so it should not be a problem.
Hi, I finally had some time to look at this issue. It turns out that the DWARF data is actually available in a few sections, whose names usually start with "debug" (.debug_info
for instance). This means that there is probably nothing to do with "my" part as described below, since you can jest get those sections by name and then get their contents as a byte array using GetContents
method. What do you think?
Yes, it was actually the byte parsing I sought after. Needed to whip up a parser for work. So in the meantime I grab the output from gdb
and parse that instead. Not sure if I'll go down this path, unfortunately. But if I do, I will probably use this plugin.
Actually, might have to back on this. Just finished my parser and the performance from GDB is terrible. I ask for all global variables and the typedefs => 6s which is fair enough. But then I flesh out all my variables (arrays and struct members) and ask for their addresses => 36s... I'll probably start to look at this in a couple of weeks.
I just uploaded my ElfParser project if anyone is interested. Works for a subset of the Dwarf2 standard (extracts type and address for variables, arrays and structs), at least using GCC.
Might work for later Dwarf standards but I currently don't have any ELF files to test with.
Great news! I'll try to finally find some time to look at the project in the new year :)
Ah, of course I stumble upon this page after I've already implemented DWARF parser. Although it works on top of PEImage (uses PEImage to extract byte streams), I'll try to see how it behaves with your nice project for ELF images :) You can find it at DWARF Symbol provider. If you have suggestions on which parts to extract out, please share them :)
I've just taken a glance, but it looks promising. The DWARF standard is vast, so it is quite hard to cover a lot, but it seems that you did some important parts. From what I can see, you've already added ELF support to your project. Does it work nicely?
It appears to work very nicely :) There is a bug with .note segment in ELF core dump. File size is ~4096, while Size is 0, so Array.Copy throws exception when calling ISegment.GetContents...
Hi southpolenator, after having to suspend development due to being really busy I am finally starting to get back to the project. So, regarding this issue:
I'm still using this project for reading elf files and elf core dumps :) Luckily, it is not blocking since in try catch block, I decided to fall back to directly read file content (which might not work in all cases): https://github.com/southpolenator/WinDbgCs/blob/MovingToCore/Source/CsDebugScript.DwarfSymbolProvider/ElfCoreDump.cs#L245 And, yes, this happens when parsing .note segment (you can see that function is being called only for Note segments).
Since the issue you have is non blocking, my plan is to first migrate the project (already done) and tests (not yet) to .NET Standard 2.0 (#36), reimplement MiscUtil (#37) and then get back to your issue. But the good news is that I plan to spend some regular time on ELFSharp every two to for weeks.
OK, I investigated it a little bit. I've decided to create two separate functions for getting contents of the segment. One uses memory size property and should be used by loaders. Second one is there if you need the file contents of the section. Old function is still there but is obsolete now (it leads to the memory function for backwards compatibility but I decided to make it obsolete, because the function's name is now misleading). Check if it works for you - release 1.3.
It would be great if you would implement a way to explore dwarf information within the .debug sections.