IMPORTANT: sourceware.org hardware migration, MARCH 18..22

Hi -

Please be aware that **next week**, we will attempt to switch over the
hardware that serves sourceware.org and its aliases (gcc.gnu.org,
ecos.sourceware.org, cygwin.com, etc.) to newer & faster hardware
donated by Red Hat.

The plan is to take down network services next Monday around 14:00Z,
and gradually bring things back up on the new machine, one service at
a time, as quickly as possible.  Since this change involves switching
to a much younger OS and is complicated by many sourceware-specific
services, the overall outage may last up to several days.  We will
prioritize getting source code version control systems up first.

This announcement is being sent to those main mailing lists that have
been recently active; please feel free to share it.  You are welcome
to listen in on irc.freenode.net #overseers during the transition
period.  We appreciate your patience and hope that the new machines
will serve us all well.

- FChE

Move tasks to bugzilla

I'd like to propose changing how we manage our task list.

Rather than have it on the wiki, I think we should file each task as a
bug in bugzilla.  We would add an "archer" tag to each task.

Then, we could replace the current list on the wiki with a bugzilla
query.

I think this would be somewhat better since it would give us a way to
track who is working on which archer task; and also let us more easily
"accept" existing bugs into archer (by just adding the tag).  This would
also give us a built-in spot to discuss any particulars of a given task,
and a simple way to indicate task dependencies (and even priorities if
we care).

Some of our tasks are a bit vague for a PR; but the vague ones aren't
really tasks so much as long-term goals or wishes.  Those could remain
on the wiki.

Any comments?

Tom

Proposal to change branch maintenance

I've been thinking a bit about how we maintain branches in archer.git
and I'd like to propose a few changes.  Let me know what you think.

First, going back to something Jan proposed years ago, I think we ought
to delete truly dead branches.  That is, if a branch has been merged
upstream and is no longer useful, let's just zap it.

Second, let's change our naming approach for new branches.  At the start
of the project I was largely ignorant of git, so I made some
obvious-in-retrospect mistakes here.

I think we should adopt the more git-like "/" separator, and drop the
"archer" prefix, as it is redundant given the repository.

So, new branches would be like "tromey/project" rather than the current
"archer-tromey-project".

I don't propose renaming existing branches.

Third, what about adopting a convention for a "README.archer" file in
the top-level of each branch?  This file would explain the branch's
purpose and would let us bypass the tedious step of updating the wiki
whenever pushing a new branch.

I think newer git even has some automated thing for documenting
branches, but unfortunately I think we aren't all on a new-enough git
yet.  We could adopt that when we're ready.

Tom

[dwz-multifile-rebase] conflict resolution; not pushed

Hi Tom,

FYI I made this local merge but I did not push it, do whatever you like with
it.

(What I pushed I also reverted and it was not a GIT-merge so it should be
a nop.)

Jan

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 8ff7dea..a257d9a 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
 <at>  <at>  -828,14 +828,8  <at>  <at>  gnulib/import/extra/snippet/arg-nonnull.h gnulib/import/extra/snippet/c++defs.h
 gnulib/import/extra/snippet/warn-on-use.h \
 gnulib/import/stddef.in.h gnulib/import/inttypes.in.h inline-frame.h skip.h \
 common/common-utils.h common/xml-utils.h common/buffer.h common/ptid.h \
-<<<<<<< HEAD
-common/linux-osdata.h gdb-dlfcn.h auto-load.h probe.h stap-probe.h gdb_bfd.h
-||||||| merged common ancestors
-common/linux-osdata.h gdb-dlfcn.h auto-load.h probe.h stap-probe.h
-=======
 common/format.h \
-common/linux-osdata.h gdb-dlfcn.h auto-load.h probe.h stap-probe.h
->>>>>>> gdb/master
+common/linux-osdata.h gdb-dlfcn.h auto-load.h probe.h stap-probe.h gdb_bfd.h

 # Header files that already have srcdir in them, or which are in objdir.

Explicit Linespecs Branch Created

Hi,

For the past few weeks, I've been working on a little project to 
implement what I've been calling "explicit linespecs." These are 
linespecs that bypass the linespec parser altogether. [Example: "break 
-function main -label foo -offset 3"]

This feature has been requested a few times, most notably as mi/13139.

A consequence of this patch series is also that all linespecs (on 
supported breakpoint types) are now converted to this explicit form. The 
addr_string is basically used for display purposes only.

Since this patchset is so large and invasive, I have checked it into the 
Archer repository for "pre-review." It's in the 
archer-keiths-explicit-linespecs branch. I would especially appreciate 
feedback on:

- Syntax of the CLI and MI breakpoint commands.

+ MI: -break-insert -c 'foo == bar' -t -e -s source.c -f function -l 
label -o offset

Currently, the explicit linespec flag (-e) must be the last option in 
the command. Everything after "-e" is restricted to explicit linespecs. 
[This restriction was enabled so that we don't have to require some 
really ugly quoting, e.g., -break-insert -e "-f main -offset 3" -c "foo 
== bar".

+ CLI: break -source source.c -function function -label label -offset 

New linespec error messages

Hi,

I'm nearly finished cleaning up my linespec rewrite. I have an enormous 
amount of bugs that I've fixed while writing some tests for it.

One thing that has evolved out of this work, though, is the ability to 
provide "better" error messages for the user. For example:

(gdb-head) b main.c:
Function "" not defined in "main.c".

(gdb-linespec-rewrite) b main.c:
malformed linespec error: unexpected EOF

Similarly, for other possible error conditions, my rewrite will 
(currently) output error messages such as:

malfomred linespec error: unexpected TOKEN[, "TOKEN_STRING"]

where TOKEN is one of the token types ("keyword", "string", "number", 
"EOF", "COLON", etc) and TOKEN_STRING is a string representation of what 
the user wrote. Here's another example:

(gdb-head) break main.c:3 +1000
Junk at end of arguments.

(gdb-linespec-rewrite) b main.c:3 +1000
malformed linespec error: unexpected number, "+1000"

Does anyone have any input on the text of these error messages? Any 

Stop the Insanity! Linespec Rewrite

Hi,

I think that most of us know the pain that is linespec.c. Well, Tom gave 
me the green light on this a while back, and I played with an initial 
design/implementation in September.

Earlier this month, I dug this out of mothballs, and it is now time to 
submit the work-in-progress for comment. This is *not* a finished design 
and/or implementation! It is simply a place to stop along the road and 
ask for advice, for a fresh set of eyes. Consider this akin to an RFC.

Let me recap what some of the more important requirements for this 
rewrite were:

- More robust parser. As several of us can attest to, adding just about 
anything to linespec.c is PAINFUL. Really painful. We need a more robust 
linespec-to-sal infrastructure.

- Consolidate similar functionality. There are several functions which 
pretty much do the same thing (e.g., decode_variable vs decode_compound 
vs the remaining bits of decode_internal).

- Rain on the quoting parade. This is actually pretty tightly coupled to 
the first requirement, but it is such a nightmare as it is now, that 
it's just worth calling out separately. I doubt I need say more.

- Enable a way for "explicit" linespecs (as I call them, for lack of a 
better term). I would like to add the ability to do, e.g., "break 
-sourcefile foo.c -function baz::doit(char*) -offset 3" and the like. 
Probably most useful to MI (and python), but not altogether useless to 

Inter-CU DWARF size optimizations and gcc -flto

Hi,

I am sorry if it is clear to everyone but I admit I played with it only
yesterday.

With
	gcc -flto -flto-partition=none

gcc outputs only single CU (Compilation Unit).  With default (omitting)
-flto-partition there are multiple CUs but still a few compared to the number
of .o files.

-flto is AFAIK the future for all the compilations.  It is well known -flto
debug info is somehow broken now but that needs to be fixed anyway.

As the DWARF size is being discussed for 5+ years I am in Tools this is
a long-term project and waiting for (helping, heh) working -flto is an
acceptable solution.

This has some implications:

(a) DWARF post-processing optimization tool no longer makes sense with -flto.

    (a1) Intra-CU optimizations in GCC make sense as it is the final output.

(b) .gdb_index will have limited scope, only to select which objfiles to expand,
    no longer to select which CUs to expand.

(c) Partial CU expansion Tom Tromey talks about is a must in such case.
    Although the smaller LTO debug info takes only 63% of GDB memory

pretty printing of smart pointers and making function calls

Hi All,

I have a couple of question related to Python pretty printers. I tried to search
for the answer on the web but had no luck.

1. For example, I want to implement a pretty printer for variable a of type
std::auto_ptr<std::string>. It's rather straight forward so I will not add here
my implementation of such printer. Then I use it as follows:

(gdb) print a
$1 = std::auto_ptr<std::string> 0x804d030

Now I want to take a look at what is the value inside that pointer.

(gdb) print *a
Could not find operator*.

How can I implement a printer for the second case?

2) Another question is about how to call from pretty printer a function from my
currently debugged process. For example, I have an unsigned int variable which
contains a hash of a string and there is a function that can map the hash to the
original string. To make the unsigned int value a bit more descriptive I want to
call the function and print corresponding string. Actually I managed to make
such call but the result looks ugly:

def to_string(self):
  crc = self.val
  s = gdb.execute('call hash_to_string(%d)' % crc, to_string=True)
  return ('crc = 0x%08X : \'%s\'' % (crc, s)))

archer@...

On Wednesday 28 December 2011 12:32:25, archer-help@... wrote:
> Hi! This is the ezmlm program. I'm managing the
> archer@... mailing list.
> 
> I'm working for my owner, who can be reached
> at archer-owner@...
> 
> To confirm that you would like
> 
>    alves.ped@...
> 
> added to the archer mailing list, please send
> an empty reply to this address:
> 
>    archer-sc.1325075545.mcfpnncjkdcpebbfingi-alves.ped=gmail.com@...
> 
> Usually, this happens when you just hit the "reply" button.
> If this does not work, simply copy the address and paste it into
> the "To:" field of a new message.
> 
> This confirmation serves two purposes. First, it verifies that I am able
> to get mail through to you. Second, it protects you in case someone
> forges a subscription request in your name.
> 
> 
> --- Administrative commands for the archer list ---
> 
> I can handle administrative requests automatically. Please
> do not send them to the list address! Instead, send
> your message to the correct command address:

archer.git "master" deletion (+branches cleanup)

Hello Jim,

there was confusion with people trying to checkout "master" from archer.git
expecting it to do something - but there is no such single branch for Archer.

I tried to delete the "master" branch but I cannot:

$ git push archer :master
remote: error: By default, deleting the current branch is denied, because the next
remote: error: 'git clone' won't result in any file checked out, causing confusion.
remote: error:
remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to
remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the
remote: error: current branch, with or without a warning message.
remote: error:
remote: error: To squelch this message, you can set it to 'refuse'.
remote: error: refusing to delete the current branch: refs/heads/master
To ssh://sourceware.org/git/archer.git
 ! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to 'ssh://sourceware.org/git/archer.git'

Could you please reconfigure it or also even delete the "master" branch there?
It works as expected on my local test git repo.  Checking out nothing by
default is IMO the best thing to do for archer.git.

(The tags are left over there, nobody is using them in Archer.)

Thanks,
Jan