Page MenuHomePhabricator

[WIP][LLD] Add output section printout
Needs RevisionPublic

Authored by ayermolo on Jan 5 2021, 5:06 PM.

Details

Summary

When debugging relocation overflow it is useful to know sizes of output sections, etc.
I added a way to print out same way that llvm-readelf does it.
For now I put it under verbose flag.
This can be split in to two commits. One refactor ELFDumper, and another LLD.
For now keeping it as one to get some feedback if community wants this, etc.

Diff Detail

Event Timeline

ayermolo created this revision.Jan 5 2021, 5:06 PM
ayermolo requested review of this revision.Jan 5 2021, 5:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 5 2021, 5:06 PM

I don't think we need this. We have D75966 (-M).

I agree with @MaskRay: does the map file solve the problem for you?

Well print-map does have size and address information scattered throughout what is potentially quite a large output. I think it will be useful to have a summary that can be quickly referenced with all the information in one place.
Maybe split the difference and add it as part of -print-map as a summary that gets printed before?

Could you give a step-by-step example of how you might use the information you want to emit? That will help us ensure that any proposals satisfy the requirements (or possibly to suggest an alternative).

Could you give a step-by-step example of how you might use the information you want to emit? That will help us ensure that any proposals satisfy the requirements (or possibly to suggest an alternative).

Sure. From memory, as I was doing it last year.
I was looking in to relocation R_X86_64_DTPOFF32 out of range issue in the unknown code base in an older version of llvm. I don't quite remember all the details at this point, but it It was useful to see what the layout was produced at a glance, what each section address, and size was. Similar to what llvm-readelf -sections outputs. Specifically as it related to .tdata/.tbss. The original theory was that maybe one of them was growing too large or linker script was messing with layout. The output, redirected to file, of print-map for that build is around 2GB. The size of each section can be just searched. Figuring out how everything laid out would require a script. I thought that having lld output summary would benefit others also, so they don't have to write a script to parse out that from output of print-map.

Could you give a step-by-step example of how you might use the information you want to emit? That will help us ensure that any proposals satisfy the requirements (or possibly to suggest an alternative).

Sure. From memory, as I was doing it last year.
I was looking in to relocation R_X86_64_DTPOFF32 out of range issue in the unknown code base in an older version of llvm. I don't quite remember all the details at this point, but it It was useful to see what the layout was produced at a glance, what each section address, and size was. Similar to what llvm-readelf -sections outputs. Specifically as it related to .tdata/.tbss. The original theory was that maybe one of them was growing too large or linker script was messing with layout. The output, redirected to file, of print-map for that build is around 2GB. The size of each section can be just searched. Figuring out how everything laid out would require a script. I thought that having lld output summary would benefit others also, so they don't have to write a script to parse out that from output of print-map.

You can use ld.lld ... -M | sed -En '/\w+ +\w+ +\w+ \S/p'

I have seen #include "\.\./ occasionally within a top-level llvm-project directory, but I don't think cross top-level directory should be allowed.

Could you give a step-by-step example of how you might use the information you want to emit? That will help us ensure that any proposals satisfy the requirements (or possibly to suggest an alternative).

Sure. From memory, as I was doing it last year.
I was looking in to relocation R_X86_64_DTPOFF32 out of range issue in the unknown code base in an older version of llvm. I don't quite remember all the details at this point, but it It was useful to see what the layout was produced at a glance, what each section address, and size was. Similar to what llvm-readelf -sections outputs. Specifically as it related to .tdata/.tbss. The original theory was that maybe one of them was growing too large or linker script was messing with layout. The output, redirected to file, of print-map for that build is around 2GB. The size of each section can be just searched. Figuring out how everything laid out would require a script. I thought that having lld output summary would benefit others also, so they don't have to write a script to parse out that from output of print-map.

You can use ld.lld ... -M | sed -En '/\w+ +\w+ +\w+ \S/p'

I have seen #include "\.\./ occasionally within a top-level llvm-project directory, but I don't think cross top-level directory should be allowed.

Thank you for sed command.
I tried it on output and it partially cleaned up output, there is still quite a bit of "typeinfo name for".
Probably command can be modified, but I think fundamentally this comes back to the same thing. Other users of lld need to know how to use sed, and if they are say on windows find alternative or write a parsing script.
This is an opt-in option that provides a better usage experience so that others don't need to re-invent the wheel.
Just a thought.

Could you give a step-by-step example of how you might use the information you want to emit? That will help us ensure that any proposals satisfy the requirements (or possibly to suggest an alternative).

Sure. From memory, as I was doing it last year.
I was looking in to relocation R_X86_64_DTPOFF32 out of range issue in the unknown code base in an older version of llvm. I don't quite remember all the details at this point, but it It was useful to see what the layout was produced at a glance, what each section address, and size was. Similar to what llvm-readelf -sections outputs. Specifically as it related to .tdata/.tbss. The original theory was that maybe one of them was growing too large or linker script was messing with layout. The output, redirected to file, of print-map for that build is around 2GB. The size of each section can be just searched. Figuring out how everything laid out would require a script. I thought that having lld output summary would benefit others also, so they don't have to write a script to parse out that from output of print-map.

You can use ld.lld ... -M | sed -En '/\w+ +\w+ +\w+ \S/p'

I have seen #include "\.\./ occasionally within a top-level llvm-project directory, but I don't think cross top-level directory should be allowed.

Thank you for sed command.
I tried it on output and it partially cleaned up output, there is still quite a bit of "typeinfo name for".
Probably command can be modified, but I think fundamentally this comes back to the same thing. Other users of lld need to know how to use sed, and if they are say on windows find alternative or write a parsing script.
This is an opt-in option that provides a better usage experience so that others don't need to re-invent the wheel.
Just a thought.

We accept new features very cautiously. Adding an option has maintenance costs and recognition cost if some options have overlapping features. You can dig up the history for previous options. They need to show values to the community. For this one, I don't think it provides any additional benefit and can just confuse users as it duplicates --print-map/-M. If you want the output, add --noinhibit-exec and inspect the output with readelf -S.

Could you give a step-by-step example of how you might use the information you want to emit? That will help us ensure that any proposals satisfy the requirements (or possibly to suggest an alternative).

Sure. From memory, as I was doing it last year.
I was looking in to relocation R_X86_64_DTPOFF32 out of range issue in the unknown code base in an older version of llvm. I don't quite remember all the details at this point, but it It was useful to see what the layout was produced at a glance, what each section address, and size was. Similar to what llvm-readelf -sections outputs. Specifically as it related to .tdata/.tbss. The original theory was that maybe one of them was growing too large or linker script was messing with layout. The output, redirected to file, of print-map for that build is around 2GB. The size of each section can be just searched. Figuring out how everything laid out would require a script. I thought that having lld output summary would benefit others also, so they don't have to write a script to parse out that from output of print-map.

You can use ld.lld ... -M | sed -En '/\w+ +\w+ +\w+ \S/p'

I have seen #include "\.\./ occasionally within a top-level llvm-project directory, but I don't think cross top-level directory should be allowed.

Thank you for sed command.
I tried it on output and it partially cleaned up output, there is still quite a bit of "typeinfo name for".
Probably command can be modified, but I think fundamentally this comes back to the same thing. Other users of lld need to know how to use sed, and if they are say on windows find alternative or write a parsing script.
This is an opt-in option that provides a better usage experience so that others don't need to re-invent the wheel.
Just a thought.

We accept new features very cautiously. Adding an option has maintenance costs and recognition cost if some options have overlapping features. You can dig up the history for previous options. They need to show values to the community. For this one, I don't think it provides any additional benefit and can just confuse users as it duplicates --print-map/-M. If you want the output, add --noinhibit-exec and inspect the output with readelf -S.

Ok, thanks for feedback/explanation.

MaskRay requested changes to this revision.Wed, Feb 10, 5:18 PM
This revision now requires changes to proceed.Wed, Feb 10, 5:18 PM

@MaskRay saw you marking this as "Needs revision", is that just a general way of not accepting diff?

MaskRay added a comment.EditedThu, Feb 11, 11:12 AM

Needs Revision is a way to make a patch not show up in reviewers' review queue, and to prevent making the patch "green" if another reviewer accepts it. It could mean the patch needs substantial change or the reviewer has substantial objection.
To save your time, I has a strong objection to the idea, given the fact that we have accepted an alternative D94560 and there are various approaches tackling with the problem.

Gotcha, thanks. Yeah I abandoned it on my end.