This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Introduce support for location views


On Jul 12, 2017, Nick Clifton <nickc@redhat.com> wrote:

> Hi Alex,

Hey, Nick!

>> This patch introduces support for specifing views in .loc directives,

> I just started testing this patch, but it fails to compile.  The error
> is:

>   gas/read.c: In function 'do_align':
>   gas/read.c:781:3: error: implicit declaration of function 'dwarf2_emit_insn'

> It looks like you are not including dwarf2dbg.h in read.c.

Yeah, config/obj-elf.h was taking care of that in my x86_64-linux-gnu
native builds.  I suppose you tested with some other non-ELF-supporting
target, eh?

> It also looks like you are calling dwarf2_emit_insn() unconditionally,
> even for targets which do not use/support the DWARF format...

*nod*

Thanks, I somehow didn't realize that would be a problem, and imagined
it would somehow sort itself out.  Doh.  Will fix.


Meanwhile, I've recently published a blog post that gives a little more
context about this project, that you guys might find interesting.
https://developers.redhat.com/blog/2017/07/11/statement-frontier-notes-and-location-views/#more-437095


Another issue I wanted to discuss is whether there's any interest in
retaining development history of this patches.  I've been working on it
in a branch, users/aoliva/SFN, and I was thinking it might make sense
for the patch that eventually gets committed to the master branch to be
a merge from the branch, that adds the consolidated ChangeLog entries,
rather than a single stand-alone commit that drops the development
history.

My reasoning is that, although we have comments and ChangeLogs and
commit messages and email archives and whatnot, some of the development
history behind certain changes will certainly be in the development
commits only, and if we don't bring those into our commit history, they
will likely be lost forever.

I can see the benefit of them when bisecting patches for the kernel
linux, for example, since a GIT pull request will bring some (possibly
revised/consolidated/rewritten/polished/cleaned-up, but still...)
development history that might shed light on issues that arise later.

We currently throw that on the floor, but there's no reason for us to do
so.  Since we use GIT for the revision history, it would be trivial to
install the consolidated patch as a merge that pulls in the development
history from the branch, along with the intended changes, if we choose
to do so.

Just to be clear, what I'm suggesting is that, when development history
for a patch is available, its commit be a pull/merge, so that the
development history becomes part of the project history even if the branch
was never published or was but gets removed later.  It would in no way
affect the checked-out tree, so the patch would add the same bits,
including ChangeLogs and whatnot, and would carry the same commit
messages that a regular commit would.

Thoughts?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]