[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172 --- Comment #5 from Matt Breedlove --- On previous builds, you could have DWARF2_UNWIND_INFO be defined and have EH_FRAME_SECTION_NAME undefined within libgcc2.c (the section name was still defined within cygming-crtbegin.c - crtbegin.o). When compiling, EH_FRAME_SECTION_NAME ends up defined while building libgcc's crtbegin.o while it was undefined during libgcc2.c preventing that extern from being emitted. Now, it is instead tied to __LIBGCC_EH_FRAME_SECTION_NAME__ which is primarily tied to DWARF2_UNWIND_INFO and part of a large amount of definitions common to both cygwin and mingw most of which I don't know the significance of. Using the new builtin causes the definition to be synchronized between crtbegin and libgcc2.c which not emits an undefined extern which fails to link. It's not a question of whether it should be reverted or not (the patch merely returned to prior behavior until a proper fix), but rather where and how it has to be changed. You can't simply undefine it within a target-section because defaults.h gets pulled into c-cppbuiltin.c right beforehand which then redefines it. There are also blocks which use DWARF2_UNWIND_INFO as a check before attempting to use it which would break those as well. I'm still waiting for input from Kai or someone more familiar with how the target should be configured. You're right though; some sort of change needs to happen there, but I don't know enough about the target's dwarf2 implementation to say what especially when other parts of the code rely on the set of definitions that make-up the following block of code in defaults.h that both decides to define it first or ultimately redefines it if we were to undefine it along the way. /* If we have named sections, and we're using crtstuff to run ctors, use them for registering eh frame information. */ #if defined (TARGET_ASM_NAMED_SECTION) && DWARF2_UNWIND_INFO \ && !defined (EH_FRAME_IN_DATA_SECTION) #ifndef EH_FRAME_SECTION_NAME #define EH_FRAME_SECTION_NAME ".eh_frame" #endif #endif
[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
--- Comment #3 from Matt Breedlove ---
In gcc/defaults.h, it gets defined via:
/* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that
the rest of the DWARF 2 frame unwind support is also provided. */
#if !defined (DWARF2_UNWIND_INFO) && defined (INCOMING_RETURN_ADDR_RTX)
#define DWARF2_UNWIND_INFO 1
#endif
/* If we have named sections, and we're using crtstuff to run ctors,
use them for registering eh frame information. */
#if defined (TARGET_ASM_NAMED_SECTION) && DWARF2_UNWIND_INFO \
&& !defined (EH_FRAME_IN_DATA_SECTION)
#ifndef EH_FRAME_SECTION_NAME
#define EH_FRAME_SECTION_NAME ".eh_frame"
#endif
#endif
This then gets pulled in to gcc/c-family/c-cppbuiltin.c at:
#ifdef EH_FRAME_SECTION_NAME
builtin_define_with_value ("__LIBGCC_EH_FRAME_SECTION_NAME__",
EH_FRAME_SECTION_NAME, 1);
#endif
INCOMING_RETURN_ADDR_RTX gets defined in gcc/config/i386/i386.h and
TARGET_ASM_NAMED_SECTION is defined in gcc/config/i386/cygming.h which is used
by both cygwin and mingw. Cygwin, however, has their own EH specific blocks
and because many of the headers are shared between it and mingw, I'm unsure
where this actually belongs.
In addition, libgcc/config/i386/cygming-crtbegin.c defines __EH_FRAME_BEGIN__
via the following:
#if DWARF2_UNWIND_INFO
static EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
__attribute__((used, section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(4)))
= { };
This passes and the symbol for it can be seen within the nm output included in
the additional_notes.txt file attached to the bug. Both of these files compile
with __LIBGCC_EH_FRAME_SECTION_NAME__ set seen below but fail the link.
crtbegin.i:
# 97 "../../../gcc/libgcc/config/i386/cygming-crtbegin.c"
static char __EH_FRAME_BEGIN__[]
__attribute__((used, section(".eh_frame"), aligned(4)))
= { };
__main_s.i:
#pragma GCC visibility pop
# 2216 "../../../gcc/libgcc/libgcc2.c" 2
extern unsigned char __EH_FRAME_BEGIN__[];
With all the target-specific blocks in the common cygwin/mingw headers, I
didn't want to go messing around with things without input since I was told
EH_FRAME_SECTION_NAME shouldn't be defined for mingw and having it undefined
will fail a number of blocks that are protected merely by DWARF2_UNWIND_INFO
being defined. The patch merely restores things back to pre-5.0 but whether
the definitions were correct then or simply masked an underlying issue and
allowed linking to pass, I'm not sure. I have the full build temps in case
anyone requires additional documentation.
[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014 --- Comment #3 from Matt Breedlove --- Created attachment 36166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36166&action=edit Patch to bypass sys_siglist and disable stpcpy builtin during bootstrap I'm currently using this patch which overrides sys_siglist detection in addition to the stpcpy built-in when building libiberty which prevents lto bootstrapping. sys_siglist causes failures in both slim and fat lto bootstraps in the later stages while the stpcpy issue remains present only within slim bootstrapping.
[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172 --- Comment #1 from Matt Breedlove --- Seems to have started with r214954. Here's the direct link to the ML post: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00409.html Per discussions with Kai, EH_FRAME_SECTION_NAME shouldn't be getting defined for mingw-w64 which it isn't while compiling libgcc2.c however the change to using _LIBGCC_EH_FRAME_SECTION_NAME__ which *is* defined while compiling this file ends up breaking linking. This is mingw specific as the modified code is in a block surrounded by an #ifndef __CYGWIN__. The complexities of gcc's dwarf2 code especially during bootstrapping are a bit beyond me. The patch above merely restores GCC 4.9 behavior for mingw but whether the change should be implemented there or in a target-specific section, I'm not sure.
[Bug target/67172] New: [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
Bug ID: 67172
Summary: [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap
fails with undefined reference to __EH_FRAME_BEGIN__
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: breedlove.matt at gmail dot com
CC: alexpux at gmail dot com, ktietz70 at googlemail dot com,
mingw.android at gmail dot com
Target Milestone: ---
Host: i686-w64-mingw32
Target: i686-w64-mingw32
Build: i686-w64-mingw32
Created attachment 36161
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36161&action=edit
Build notes, save-temps, object files
GCC 5/6 branches fail to bootstrap starting with the beginning of GCC 5
releases configured as:
./configure \
--prefix=/mingw32 --with-local-prefix=/mingw32/local \
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--target=i686-w64-mingw32 \
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include \
--libexecdir=/mingw32/lib \
--with-gxx-include-dir=/mingw32/include/c++/6.0.0 \
--enable-bootstrap \
--with-arch=i686 --with-tune=generic \
--enable-languages=c,lto,c++ \
--enable-shared --enable-static \
--enable-threads=posix \
--enable-libatomic --enable-graphite --enable-fully-dynamic-string \
--enable-libstdcxx-time=yes \
--disable-libstdcxx-pch --disable-libstdcxx-debug \
--enable-version-specific-runtime-libs \
--disable-isl-version-check \
--enable-lto --enable-libgomp --enable-checking=release \
--disable-multilib --disable-rpath --disable-win32-registry
--disable-nls --disable-werror --disable-symvers \
--with-libiconv --with-system-zlib \
--with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32
--with-isl=/mingw32 \
--with-gnu-as --with-gnu-ld \
--disable-sjlj-exceptions --with-dwarf2
Problem discussed here:
http://sourceforge.net/p/msys2/mailman/msys2-users/thread/c48f5a81-8875-4b57-8668-d1d737c8a...@gmail.com/
The following patch reverts behavior to pre-5.0 behavior and allows building
and is in active use in msys2:
diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c
index c737620..e5ab209 100644
--- a/libgcc/libgcc2.c
+++ b/libgcc/libgcc2.c
@@ -2211,7 +2211,7 @@ TRANSFER_FROM_TRAMPOLINE
/* Some ELF crosses use crtstuff.c to provide __CTOR_LIST__, but use this
code to run constructors. In that case, we need to handle EH here, too.
*/
-#ifdef __LIBGCC_EH_FRAME_SECTION_NAME__
+#ifdef EH_FRAME_SECTION_NAME
#include "unwind-dw2-fde.h"
extern unsigned char __EH_FRAME_BEGIN__[];
#endif
@@ -2231,7 +2231,7 @@ __do_global_dtors (void)
(*(p-1)) ();
}
#endif
-#if defined (__LIBGCC_EH_FRAME_SECTION_NAME__) && !defined (HAS_INIT_SECTION)
+#if defined (EH_FRAME_SECTION_NAME) && !defined (HAS_INIT_SECTION)
{
static int completed = 0;
if (! completed)
@@ -2250,7 +2250,7 @@ __do_global_dtors (void)
void
__do_global_ctors (void)
{
-#ifdef __LIBGCC_EH_FRAME_SECTION_NAME__
+#ifdef EH_FRAME_SECTION_NAME
{
static struct object object;
__register_frame_info (__EH_FRAME_BEGIN__, &object);
I've attached the build logs, -save-temps=obj output, and some additional
notes. If you can't find what you need in that file, I've put what couldn't
fit or probably isn't really wanted below:
https://drive.google.com/file/d/0B6Y2OcAf3yVKWTRaaWxtSEJjMGM/view?usp=sharing
[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014 --- Comment #1 from Matt Breedlove --- This issue is still present on 5.1.0 and trunk. The issue seems to be related to libiberty's implementation of stpcpy being replaced with the GCC builtin and then causing linker errors due to that symbol not being defined when attempting to link lto-plugin. Passing in -fno-builtin-stpcpy when building libiberty has resolved this for me and allows the build to progress but I'm unsure if there is any other potential fallout from similar issues.
[Bug lto/66014] New: 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014 Bug ID: 66014 Summary: 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy' Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: breedlove.matt at gmail dot com Target Milestone: --- Created attachment 35461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35461&action=edit save-temps and object files for pex-win32 and stpcpy Following the fix in PR 65559 (though LTO didn't work at all previously), GCC on mingw64 is unable to perform a slim bootstrap, dying when building liblto_plugin-0.dll. Normal -ffat-lto-object builds unaffected. /bin/sh ./libtool --tag=CC --tag=disable-static --mode=link /build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc -B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/ -B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/x86_64-w64-mingw32/sys-include-Wall -O2 -march=x86-64 -mtune=native -flto=jobserver -frandom-seed=1 -Wc,-static-libgcc -no-undefined -bindir "/mingw64/bin/gcc-5.1.0" -module -bindir /mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0 -Wc,../libiberty/libiberty.a -Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc' '-Wl,--stack,12582912' -o liblto_plugin.la -rpath /mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0 lto-plugin.lo libtool: link: /build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc -B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/ -B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/x86_64-w64-mingw32/sys-include-shared .libs/lto-plugin.o -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -march=x86-64 -mtune=native -static-libgcc ../libiberty/libiberty.a -static-libstdc++ -static-libgcc -Wl,--stack -Wl,12582912 -o .libs/liblto_plugin-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/liblto_plugin.dll.a M:\mingw64\tmp\cc5tPjOg.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy' collect2.exe: error: ld returned 1 exit status Makefile:351: recipe for target 'liblto_plugin.la' failed make[1]: *** [liblto_plugin.la] Error 1 make[1]: Leaving directory '/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/lto-plugin' Makefile:264: recipe for target 'all' failed make: *** [all] Error 2 This is following the fix to GCC by including specific object files in archives rather than the entire library. The following shows that no symbols appear within the slim objects for the (should be defined) stpcpy in stpcpy.o as well as the undefined symbol in pex-win32.o $ nm --plugin prev-lto-plugin/.libs/liblto_plugin-0.dll libiberty/pex-win32.o U _close U _dup U _errno U _get_osfhandle U _open U _pipe U _read U CloseHandle U CreateFileA U CreateProcessA U fdopen T funcs U getenv U GetExitCodeProcess U GetVersionExA T pex_init U pex_init_common U qsort U SetHandleInformation U WaitForSingleObject U xmalloc $ nm -a libiberty/pex-win32.o b .bss d .data r .gnu.lto_.decls.1 r .gnu.lto_.inline.1 r .gnu.lto_.opts r .gnu.lto_.refs.1 r .gnu.lto_.symbol_nodes.1 r .gnu.lto_.symtab.1 r .gnu.lto_argv_to_argc.1 r .gnu.lto_argv_to_cmdline.1 r .gnu.lto_backslashify.1 r .gnu.lto_env_compare.1 r .gnu.lto_find_executable.1 r .gnu.lto_funcs.1 r .gnu.lto_pex_init.1 r .gnu.lto_pex_win32_close.1 r .gnu.lto_pex_win32_exec_child.1 r .gnu.lto_pex_win32_fdopenr.1 r .gnu.lto_pex_win32_fdopenw.1 r .gnu.lto_pex_win32_open_read.1 r .gnu.lto_pex_win32_open_write.1 r .gnu.lto_pex_win32_pipe.1 r .gnu.lto_pex_win32_wait.1 r .gnu.lto_spawn
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #33 from Matt Breedlove ---
bootstrap-lto fails to build:
`isl_union_map_read_from_str' referenced in section `.text' of
M:\msys64\tmp\cceOtKWH.ltrans0.ltrans.o: defined in discarded section `.text'
of isl_input.o (symbol from plugin)
`isl_union_map_read_from_str' referenced in section `.text' of
M:\msys64\tmp\cceOtKWH.ltrans0.ltrans.o: defined in discarded section `.text'
of isl_input.o (symbol from plugin)
`isl_union_map_copy' referenced in section `.text' of
M:\msys64\tmp\cceOtKWH.ltrans0.ltrans.o: defined in discarded section
...
Replacing the lto-wrapper with the one from my previous build makes these
errors disappear. The patch from my previous build was the following:
--- gcc-5.1.0/gcc/lto-wrapper.c.orig2015-05-01 16:38:03.348243300 -0400
+++ gcc-5.1.0/gcc/lto-wrapper.c 2015-05-02 00:30:58.345729900 -0400
@@ -934,7 +934,7 @@
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (filename, O_RDONLY|O_BINARY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
Rainer hasn't tested this yet. I'm going to do a full native bootstrap-lto
with this, however it was working fine on everything else I compiled. The
issue with the last tested patch was archive files with offsets were getting
discarded from the build since we were back to not using the parsed archive
filename.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #32 from Matt Breedlove --- I've been building with just the corrected open call and have successfully built LTO versions of binutils, mpc, mpfr, isl, libiconv, bzip2, zlib, etc without any issue but have had issues on doing a bootstrap-lto with it. I'll try the last patch and do a native bootstrap-lto build with it and report back shortly.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #28 from Matt Breedlove ---
(In reply to Rainer Emrich from comment #26)
> (In reply to Rainer Emrich from comment #25)
> > (In reply to Richard Biener from comment #24)
> > > Note that the issue should only cause option merging to be skipped for
> > > files
> > > in archives (and that, too, on x86_64-linux). Though compared to the 4.9
> > > branch
> > > we do
> > >
> > > fd = open (argv[i], O_RDONLY);
> > > if (fd == -1)
> > > {
> > > lto_argv[lto_argc++] = argv[i];
> > > continue;
> > > }
> > >
> > > vs.
> > >
> > > fd = open (argv[i], O_RDONLY);
> > > if (fd == -1)
> > > continue;
> > >
> > > so we add the file to later processing even if we failed to open it.
> > > Thus,
> > > does removing _that_ also fix the issue?
> >
> > Native bootstrap for c,c++ started on x86_64-w64-mingw32. I will run the
> > testsuite afterwards. Results expected in about 4 hours.
>
> Tested patch:
>
> Index: gcc/lto-wrapper.c
> ===
> --- gcc/lto-wrapper.c (Revision 222611)
> +++ gcc/lto-wrapper.c (Arbeitskopie)
> @@ -936,10 +936,7 @@ run_gcc (unsigned argc, char *argv[])
> }
>fd = open (argv[i], O_RDONLY);
>if (fd == -1)
> - {
> - lto_argv[lto_argc++] = argv[i];
> - continue;
> - }
> + continue;
>
>if (find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
> &fdecoded_options, &fdecoded_options_count,
>
>
>
> Doesn't help, lto failures back again!
Rainer,
If you don't mind, what were the failures you were getting on this one or did
the original reported errors simply return?
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #27 from Matt Breedlove --- The primary differences between the 4.9 branch and 5.1.0 are only that the underlying issue now results in a fatal error. In the 4.9 branch, the objects and archives (even "-fresolution=libarchive.res" verbatim) are opened to see whether they exist and if so, then are parsed for LTO options. In 4.9, if they fail to be opened as files *or* if they fail have parse-able LTO section, they are still passed along the command-line. Currently in 5.1.0 (without patches listed here), if a file does not exist (such as an archive with an offset since argv[i] is used) then it is not parsed for LTO sections and passed along as-in. If an object is found, then it is parsed for LTO sections and passed along only if it has those sections. The real question is what behavior should be given if a non-LTO object is passed along with an LTO build. This wasn't a problem before because in 4.9 and prior, even when it failed to parse LTO sections for that file, the file would still be passed along on the command-line. With the current functionality, I believe failing to parse the file and failing to find LTO sections within the file are essentially equivalent in which case the file is not passed along any longer. The problem with Richard's patch seems opposite to me. Since lto_argv is used as a container to hold the objects/archives that are passed along into the output, these should likely contain all objects/archives whether they have LTO options with them or not or the result is that we're simply dropping objects. The reason that there weren't failures on archive files previously is precisely because we are adding files that do not exist explicitly to that array when we fail to open them which has hidden the underlying issue in previous versions. The lines below show how these objects are being added to the output: /* Append the input objects and possible preceding arguments. */ for (i = 0; i < lto_argc; ++i) obstack_ptr_grow (&argv_obstack, lto_argv[i]); Where do the objects that don't have LTO sections go? Nowhere. These issues are present in previous versions but went unnoticed for the only reason that there was no temporary lto_argv array.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Matt Breedlove changed: What|Removed |Added CC||breedlove.matt at gmail dot com --- Comment #19 from Matt Breedlove --- Kai, This corrects issue #2 from my ML post (https://gcc.gnu.org/ml/gcc/2015-04/msg00355.html) but should this not be something like the following instead? fd = open (filename, O_RDONLY|O_BINARY); With how things are currently written in the code, archive libraries will always fail to be opened properly since the code used to parse their file names and offsets will always chuck out the work that is being done. Toward the top of the loop, we're setting "char *filename = argv[i];" and then overriding it when we hit a filename with an offset but then using the original un-parsed command-line parameter when trying to open the file to see if it exists. Ex: Parameter: libarchive.a@0x42e20 Parsed as: filename = libarchive.a offset = 0x42e20 File opened: libarchive.a@0x42e20 (instead of libarchive.a) >From looking at the code, this has been this way for quite awhile. I tested the change after modifying it to use the filename variable instead and it works successfully rather than simply failing to open any archive passed in with an offset.
