Add the possibility to have two files in entry and then merge their info#91
Add the possibility to have two files in entry and then merge their info#91calixteman merged 5 commits intomozilla:masterfrom
Conversation
gabrielesvelto
left a comment
There was a problem hiding this comment.
This seems OK overall but I feel there's some unrelated changes which I'd like to see split into another patch if possible.
| buf_1: Vec<u8>, | ||
| filename_1: String, | ||
| buf_2: Vec<u8>, | ||
| filename_2: String, |
There was a problem hiding this comment.
If there's an order to those files it'd be better to give them more meaningful names such as buffer_stripped and buffer_debuginfo. Alternatively it would be better to use an array which might be useful when symbols are stripped across more than two files.
There was a problem hiding this comment.
Agreed, we can do that in an other commit
| }) | ||
| } | ||
|
|
||
| pub fn merge(left: ElfInfo, right: ElfInfo) -> ElfInfo { |
There was a problem hiding this comment.
I must admit I'm a bit stumped by this. I thought that symbolic would already have functionality to present a single view of a PE+PDB or .so+.dbg couple. It's a bit sad to see we have to merge the debuginfo ourselves.
|
|
||
| /// Set the location where the inlinees are inlined in the inliner | ||
| /// We use this function when some addresses in an inlinee are before the function start | ||
| fn set_line_info(&mut self, line: &LineInfo, compilation_dir: &[u8], source: &mut SourceFiles) { | ||
| if let Some(inlinee_pos) = self.addresses.get(&line.address) { | ||
| let inlinee = &mut self.inlinees[*inlinee_pos]; | ||
| if inlinee.start == line.address { | ||
| let file_id = source.get_id(compilation_dir, &line.file); | ||
| inlinee.location = ElfLineInfo { | ||
| file_id, | ||
| line: line.line as u32, | ||
| }; | ||
| } | ||
| } |
There was a problem hiding this comment.
This and the other changes to the inlined functions seem unrelated to the multi-file support. Is this the functionality that was recently merged into symbolic? If it is it would be best to split it out into another patch for clarity.
There was a problem hiding this comment.
I moved that stuff in a separate commit.
No description provided.