On 5/2/24 2:47 AM, Richard Biener via Overseers wrote:> We'd only know for sure
if we try. But then I'm almost 100% sure that
> having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA
> I am using for "quick" patch review. It might be comparable to the
> review parts I do in
On 2024-05-01 16:53, Tom Tromey via Overseers wrote:
> Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997
> Mark> We really should automate this. There are several people running
> Mark> scripts by hand. The easiest would be to simply run it from a git
> Mark> hook. patchwork
On 2024-04-23 11:08, Tom Tromey wrote:
>> Indeed. Though Patchwork is another option for patch tracking, that
>> glibc seem to be having success with.
>
> We tried this in gdb as well. It was completely unworkable -- you have
> to manually clear out the patch queue, meaning it's normally
On 2024-04-22 22:55, Jason Merrill via Overseers wrote:
> On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote:
>
>>> "Frank" == Frank Ch Eigler writes:
>>
[...] I suggest that a basic principle for such a system is that it
should be *easy* to obtain and maintain a local copy of the
On 2024-04-04 17:35, Mark Wielaard wrote:
> Hi Christophe,
>
> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote:
>> TL;DR: For the sake of improving precommit CI coverage and simplifying
>> workflows, I’d like to request a patch submission policy change, so
>> that we
On 4/3/24 4:22 AM, Christophe Lyon via Gdb wrote:
> Dear release managers and developers,
>
> TL;DR: For the sake of improving precommit CI coverage and simplifying
> workflows, I’d like to request a patch submission policy change, so
> that we now include regenerated files. This was discussed
On 2024-03-15 10:25, Tom Tromey wrote:
> gdb used to use a mish-mash of different approaches, some quite strange,
> but over the last few years we standardized on Python scripts that
> generate files. They're written to be seamless -- just invoke in the
> source dir; the output is then just
On 3/18/24 13:25, Christophe Lyon wrote:
> Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit
> more complex
> than just calling automake. IIUC it calls automake --foreign it any of
> *.m4 file from $(am__configure_deps) that is newer than Makefile.in
> (with an early exit in the
On 3/18/24 13:28, Christophe Lyon via Gdb wrote:
> I'm not up-to-date with gdb's policy about patches: are they supposed
> to be posted with or without the regenerated parts included?
> IIUC they are not included in patch submissions for binutils and gcc,
> which makes the pre-commit CI miss some
On 2024-03-15 04:50, Christophe Lyon via Gdb wrote:
> On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
>> My first thought it: why is it a Makefile target, instead of some script
>> on the side (like autoregen.sh). It would be nice / useful to be
>> able to it without configuring / building
On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> Hi!
>
> After recent discussions on IRC and on the lists about maintainer-mode
> and various problems with auto-generated source files, I've written
> this small prototype.
>
> Based on those discussions, I assumed that people generally
Hi gcc-patches,
I had applied the patch below to binutils-gdb, but it recently got wiped
out by a gcc -> binutils-gdb configure.ac sync. Would it be possible to
apply it to the gcc repo so this doesn't happen again?
Thanks,
Simon
On 2022-03-15 17:26, Simon Marchi via Gdb-patches wrote:
>
Add
AC_CONFIG_MACRO_DIRS([../config])
So that just running:
$ autoreconf -vf
... does the right thing (no need to specify -I ../config).
Note: I don't have access to the gcc repo, so if this patch is approved,
can somebody push it there on my behalf? I can push it to binutils-gdb.
On 2022-04-08 10:32, Nick Clifton wrote:
> Hi Simon,
>
>> Ping.
>
> Patch approved - please apply.
>
> I appreciate that modifying these top level files is a bit nerve
> wracking, but I think that you have done a good job in this case. :-)
>
> Cheers
> Nick
>
Thanks Nick, pushed.
Simon
Ping.
On 2022-03-29 16:04, Simon Marchi wrote:
> Ping!
>
> On 2022-03-15 17:26, Simon Marchi wrote:
>> From: Simon Marchi
>>
>> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
>> top-level Makefile/configure]
>>
>> I have my debuginfod library installed in a non-standard
Ping!
On 2022-03-15 17:26, Simon Marchi wrote:
> From: Simon Marchi
>
> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
> top-level Makefile/configure]
>
> I have my debuginfod library installed in a non-standard location
> (/opt/debuginfod), which requires me to set
>
From: Simon Marchi
[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]
I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set
On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> Hi Guys,
>
> On 4/30/21 7:36 PM, Simon Marchi wrote:
>> I think this fix is obvious enough, I encourage you to push it,
>
> OK - I have pushed the patch to the mainline branches of both
> the gcc and binutils-gfdb repositories.
>
> Cheers
>
On 2021-05-03 5:51 p.m., Alan Modra wrote:
> I wasn't talking about running configure, I was talking about running
> make. For example, you configure and make binutils as usual, then
> after making a change to ld/ files, run make in the ld build dir. I
> don't tend to do that myself but I do run
> Yes, I prefer the configure fix too. If we state we require C99 in
> binutils then we ought to be able to use C99..
>
> Nick, does the configure.ac change also need to go in all subdirs, to
> support people running make in say ld/ rather than running make in the
> top build dir?
For GDB, it's
On 2021-04-26 7:32 a.m., Nick Clifton via Gdb-patches wrote:> Hi Guys,
>
> Given that gcc, gdb and now binutils are all now requiring C99 as a
> minimum version of C, are there any objections to updating
> configure.ac to reflect this ?
>
> Cheers
> Nick
>
> diff --git a/configure.ac
On 2021-04-08 9:11 a.m., David Edelsohn wrote:
>>> AIX continues to use and support STABS, although it is transitioning
>>> to DWARF. If this is intended as a general statement about removal of
>>> STABS support in GCC,
>>
>> Yes, it is.
>>
>> Richard.
>
> Richard,
>
> It is inappropriate to
On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM
Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
>
> The default debug format (when using only -g) for the AVR target is
> stabs. Is there a reason for it not being DWARF, and would it
Hi,
The default debug format (when using only -g) for the AVR target is
stabs. Is there a reason for it not being DWARF, and would it be
possible to maybe consider possibly thinking about making it default to
DWARF? I am asking because the support for stabs in GDB is pretty much
untested and
Bring in a few lines that are in binutils-gdb's .gitignore but not
gcc's.
Note that I don't have push access to gcc, so I would appreciate
if somebody could push it for me.
ChangeLog:
* .gitignore: Sync with binutils-gdb.
---
.gitignore | 7 +++
1 file changed, 7 insertions(+)
On 2020-11-13 10:18 a.m., Mark Wielaard wrote:
> That too, but I was actually referring to the sections that define
> Range List and Location List Tables (7.28 and 7.29) which define the
> meaning of DW_AT_rnglists_base and DW_AT_loclists_base. But you could
> also look at 3.1.3 Split Full
On 2020-11-12 7:11 p.m., Mark Wielaard wrote:
> Hi Simon,
>
> On Thu, Nov 05, 2020 at 11:11:43PM -0500, Simon Marchi wrote:
>> I'm currently squashing some bugs related to .debug_rnglists in GDB, and
>> I happened to notice that clang and gcc do different things when
>> generating rnglists with
Hi,
I'm currently squashing some bugs related to .debug_rnglists in GDB, and
I happened to notice that clang and gcc do different things when
generating rnglists with split DWARF. I'd like to know if the two
behaviors are acceptable, and therefore if we need to make GDB accept
both. Or maybe
28 matches
Mail list logo
