echristo added a comment.
In https://reviews.llvm.org/D52296#1285328, @grimar wrote:
> In https://reviews.llvm.org/D52296#1284130, @probinson wrote:
>
> > In https://reviews.llvm.org/D52296#1283691, @grimar wrote:
> >
> > > Nice :)
> > > So seems the last unresolved question left is the naming
grimar added a comment.
In https://reviews.llvm.org/D52296#1284130, @probinson wrote:
> In https://reviews.llvm.org/D52296#1283691, @grimar wrote:
>
> > Nice :)
> > So seems the last unresolved question left is the naming of the new option?
> > If we do not want to go with
probinson added a comment.
In https://reviews.llvm.org/D52296#1283691, @grimar wrote:
> Nice :)
> So seems the last unresolved question left is the naming of the new option?
> If we do not want to go with `-gsingle-file-split-dwarf` then what it should
> be?
>
> What about `-fdebug-fission`
grimar added a comment.
Nice :)
So seems the last unresolved question left is the naming of the new option?
If we do not want to go with `-gsingle-file-split-dwarf` then what it should be?
What about `-fdebug-fission` as an alias for `-gsplit-dwarf`.
And `-fsingle-file-debug-fission` for the
dblaikie added a comment.
In https://reviews.llvm.org/D52296#1282603, @probinson wrote:
> In https://reviews.llvm.org/D52296#1282589, @dblaikie wrote:
>
> > In https://reviews.llvm.org/D52296#1282587, @probinson wrote:
> >
> > > Any distributed build has to make this work, so the paths in the
probinson added a comment.
In https://reviews.llvm.org/D52296#1282589, @dblaikie wrote:
> In https://reviews.llvm.org/D52296#1282587, @probinson wrote:
>
> > Any distributed build has to make this work, so the paths in the line table
> > are usable. Not clear what you're thinking might be the
dblaikie added a comment.
In https://reviews.llvm.org/D52296#1282587, @probinson wrote:
> In https://reviews.llvm.org/D52296#1282458, @dblaikie wrote:
>
> > I guess in that case your distributed build system would have a constraint
> > that it always ships all the object files back to the
probinson added a comment.
In https://reviews.llvm.org/D52296#1282458, @dblaikie wrote:
> I guess in that case your distributed build system would have a constraint
> that it always ships all the object files back to the primary machine (where
> you'd be running the debugger)? (perhaps it just
dblaikie added a comment.
In https://reviews.llvm.org/D52296#1282369, @grimar wrote:
> In https://reviews.llvm.org/D52296#1281642, @echristo wrote:
>
> > Can you elaborate on your motivations and what you're trying to do?
> >
> > Thanks!
>
>
> We want to see:
>
> - No extra files. The compiler
grimar added a comment.
In https://reviews.llvm.org/D52296#1281642, @echristo wrote:
> Can you elaborate on your motivations and what you're trying to do?
>
> Thanks!
We want to see:
- No extra files. The compiler produces just a .o.
- The linker leaves most debug info in the .o files.
That
echristo added a comment.
In https://reviews.llvm.org/D52296#1246142, @grimar wrote:
> In https://reviews.llvm.org/D52296#1243688, @echristo wrote:
>
> > In https://reviews.llvm.org/D52296#1241928, @probinson wrote:
> >
> > > Do we generate the .dwo file directly these days? If not, I can
grimar updated this revision to Diff 171480.
grimar added a comment.
Ping.
- Rebased.
https://reviews.llvm.org/D52296
Files:
include/clang/Driver/CC1Options.td
include/clang/Driver/Options.td
include/clang/Frontend/CodeGenOptions.h
lib/CodeGen/BackendUtil.cpp
dblaikie added a comment.
In https://reviews.llvm.org/D52296#1272220, @grimar wrote:
> Maybe `-gno-dwo`? So we would write `-genable-split-dwarf -gno-dwo`?
I'm not sure how everyone else feels about "-g" flags that modify debug
behavior (like "-gsplit-dwarf") versus "-f" flags (eg:
grimar added a comment.
Maybe `-gno-dwo`? So we would write `-genable-split-dwarf -gno-dwo`?
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dblaikie added a comment.
@echristo
> As far as the standard text here, IMO it was just there in case people didn't
> have an objcopy around or don't want to split it. I'm not sure why we would
> want the ability.
I think others have mentioned - but with distributed build it might be easier
alexshap added a comment.
I talked to David @dblaikie offline about this diff yesterday, if I understood
correctly this change is reasonable in general, @echristo Eric, would you mind
having a look at this diff ?
https://reviews.llvm.org/D52296
alexshap added a comment.
Ping
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexshap added a comment.
I see, many thanks. I've cherry-picked this patch locally and played with GDB -
it appears to work fine with it.
I'm also interested and support this change since this would simplify the
adoption of Fission by some build systems.
@dblaikie, @echristo - are there any
grimar added a comment.
In https://reviews.llvm.org/D52296#1258677, @alexshap wrote:
> @grimar, this is an interesting observation which I've had on my mind for
> quite some time as well; a couple of things which I have not double-checked
> yet - just in case - do both gold and lld completely
alexshap added a comment.
@grimar, this is an interesting observation which I've had on my mind for quite
some time as well; a couple of things which I have not double-checked yet -
just in case - do both gold and lld completely ignore dwo-related sections ?
(did you check that ?), and another
grimar added a comment.
Ping.
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
grimar added a comment.
Ping.
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
grimar added a comment.
In https://reviews.llvm.org/D52296#1243688, @echristo wrote:
> In https://reviews.llvm.org/D52296#1241928, @probinson wrote:
>
> > Do we generate the .dwo file directly these days? If not, I can imagine
> > wanting to avoid the overhead of the objcopy hack; as long as
echristo added a comment.
In https://reviews.llvm.org/D52296#1241928, @probinson wrote:
> Do we generate the .dwo file directly these days? If not, I can imagine
> wanting to avoid the overhead of the objcopy hack; as long as the linker is
> smart enough not to bother with the .debug_*.dwo
echristo added a comment.
In https://reviews.llvm.org/D52296#1241928, @probinson wrote:
> Do we generate the .dwo file directly these days? If not, I can imagine
> wanting to avoid the overhead of the objcopy hack; as long as the linker is
> smart enough not to bother with the .debug_*.dwo
grimar added a comment.
To summarise:
- It shares most of the benefits with the .dwo solution.
- Unlike .dwo, there is no need to split the file and it is friendlier to other
tools (ccache, distcc, etc)
- But unlike .dwo a distributed build system has to copy larger .o files.
grimar added a comment.
We want to take the benefit that debug fission provides, but keep the debug
information in the objects.
That is a bit less intrusive way than using regular split dwarf flow.
For a regular build and debug cycle that allows the linker to do minimal
processing of the
probinson added a comment.
Do we generate the .dwo file directly these days? If not, I can imagine
wanting to avoid the overhead of the objcopy hack; as long as the linker is
smart enough not to bother with the .debug_*.dwo sections this seems like a
build-time win.
dblaikie added a comment.
Do you/what's your particular use case for this scenario? I guess this looks a
bit like Apple's format (where debug info stays in the object file and isn't
linked into the final binary), but don't expect they'd be moving to this any
time soon.
grimar created this revision.
grimar added reviewers: dblaikie, echristo, probinson, compnerd.
Herald added subscribers: JDevlieghere, aprantl.
The DWARF5 specification says(Appendix F.1):
"The sections that do not require relocation, however, **can be written to the
relocatable object (.o)
30 matches
Mail list logo